GNOME.org
 

Re: [Ekiga-list] destructive Ekiga Win-XP un-install [FIXED]

On 08/05/10 16:20, David Ford wrote:

Hi Eugen

On 08/05/10 14:07, Eugen Dedu wrote:

On 08/05/10 14:28, David Ford wrote:

Hi Eugen

On 08/05/10 13:12, Eugen Dedu wrote:

On 06/05/10 14:03, Eugen Dedu wrote:

On 06/05/10 07:54, Eugen Dedu wrote:

On 05/05/10 20:53, michel memeteau wrote:

2010/5/5 Eugen Dedu<Eugen Dedu pu-pm univ-fcomte fr>


On 14/02/10 14:57, michel memeteau wrote:


if for some reason the installer decide that MyDocs is the default
install
dir instead of progfiles/ekiga , it will install there and
uninstaller
will
erase the INSTALDIR content and thus mydocs.
I guess it can have something to do with user rights as if
progfiles is
not
writable, i might try Mydocs. I've seen this behaviour before.

Well... I have just had it too...

I use a computer of my school. echo %programfiles% shows C:\Program
Files.
I tried to create a directory inside, I do not have the right to
do it.
When I start ekiga-setup, it proposes me to install in C:\Docs and
Settings\ededu/Ekiga. I have not yet completed the install process.




"Good news " ! Eugen. I don't think it's that weird that the NSIS
process
would detect that the user does not have any rights under XP and
thus
propose a D&S/username/Ekiga install dir.

I even think that the firefox installer do this to. So IMO it's
not a
bug to
correct.

The main bug is that the uninstaller remove D&S/username whole
folder
which
means the regedit uninstall key is not correctly read.


Here is the progress so far:
- as shown at http://www.flickr.com/photos/34403391 N07/4356542596/,
the
installer did not install ekiga in a new directory (look at ekiga,
help,
locale, icons directories, which belong to ekiga), but directly in
MyDocuments, where other files reside
- I think that yesterday everything was ok for me anyway, since it
proposed a new directory (ending in Ekiga)
- the NSIS script in ekiga uses during uninstall (cf.
http://git.gnome.org/browse/ekiga/tree/win32/nsisinstaller/ekiga.nsi?h=gnome-2-26):




Delete /REBOOTOK "$INSTDIR\*.*"
RMDir /r /REBOOTOK "$INSTDIR"
which of course removes the whole installation directory (by the way,
aren't both these commands identical??) This is unsafe anyway, as
shown
at the end of the section
http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.1.8

I try to understand now:
- why the installer have not proposed a new directory (ending in
\Ekiga). Reporter, have you installed it in MyDocs or in
MyDocs\Ekiga?
Have you modified the directory it proposed you or not?
- how to avoid delete *\*, since by the way the uninstallation might
work even if the user himself chooses an already existing and non
empty
directory


After reading the source code and playing a bit with the installer, I
understood what happened.

The installer proposed to install in C:\D&S\ededu\Ekiga. If I click on
Browse..., then the new dialog is as shown at
http://eugen.dedu.free.fr/inst3.png. If I wrongly click on Ok
instead of
Cancel, then the installation directory changes to
C:\D&S\ededu\MyDocs.
I continue the installation.

Upon uninstallation, as shown above, nsis code in ekiga removes the
installation directory completely, so everything in
C:\D&S\ededu/MyDocs.

Now, I have the solution and a question. The solution is to remove the
files one by one, as it is done in pidgin
(http://developer.pidgin.im/viewmtn/revision/file/2024012eee484e1d27fff17f648e83e13dd0fd5d/pidgin/win32/nsis/pidgin-installer.nsi,


search for CAcert and look at all the following lines). Or better but
more complicated, save all the installed files in a log and remove
them
upon uninstallation
(http://nsis.sourceforge.net/Uninstall_only_installed_files).

And the question is: is it normal that Browse... show the attached
window instead of going to the proposed installation directory (well,
Ekiga subdir in the installation directory does not exist)??

Finally, the installation directory has GTK... as title. Does this
mean
that it is the gtk code which does this, and not ekiga nsis code?


I have finally fixed this bug:
http://git.gnome.org/browse/ekiga/commit/?h=gnome-2-26&id=2d1d493c126d76c0709051fb3104d6f261c0acb4




If I had not interrupted the uninstall, what would have happened when
the uninstaller emptied the My Documents directory? Would it then
have started deleting files a level higher in the directory
hierarchy, and continued until it erased the entire hard drive?


For info: Until now, the uninstaller removed the whole installation
directory, and in your case Ekiga was installed in MyDocs. It did not
jumped to upper directory.

The simplest solution I found is that if the installation directory is
not empty (such as MyDocs), then it is installed into an empty
sub-directory. Thus, even when the uninstall removes the whole
sub-directory, there is no problem.


Does this mean that if you install Ekiga in a new XP installation with
an empty MyDocs it will be installed in MyDocs and not in a sub-dir?
Later docs going into MyDocs could still be lost.
Wouldn't it be better to always create it's own sub-dir?


Well, I thought of this too. So you propose to create always a subdir
called Ekiga and install in it and remove it completely? What if the
user chooses as install dir C:/ProgF/Ekiga? Then the installation is
done in C:/ProgF/Ekiga/Ekiga...

Or maybe if the directory proposed by user is called E(e)kiga and if
it is empty, then install in it, elsewhere create Ekiga subdir and
install in it?


That sounds good! It should cater for people who want to type things in
and people who just hit 'Enter'
Ekiga/Ekiga isn't a big problem though. Do the user account details get
stored in /Ekiga in Windows? Would uninstalling and reinstalling loose
all your contacts?
Ok, implemented like this, see http://git.gnome.org/browse/ekiga/commit/?h=gnome-2-26&id=71ecb6d1c96075ffc9b98e21412b32c28dc9d779
Account details are stored in %appdata%/ekiga.conf, I do not yet know if they are removed. Should they be removed or not? 

--
Eugen
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]