Incomplete uninstall of wine applications

[gold_Single]

When I uninstall an application with the Uninstall Wine Application, it erases all the folders of this application but the application uninstalled stills in Applicationx->Wine. Why?

[Sam Peterson (peabodyenator)]

As far as I can tell, there's poor coupling between wine and the applications menu. It's sort of a one way deal. While it's not that important. It would be nice to have this fixed.

[Loye Young (loyeyoung)]

On Sunday, October 14, 2007 6:09:54 am Sam Peterson wrote:
>While it's not that
> important. It would be nice to have this fixed.

It's only not important if you know what's going on. Regular users, especially
those who are installing Windows apps, don't know (nor should have to care)
what's going on behind the scenes. Users are just going to think it's still
installed, but merely turned off.

I vote for a higher importance level.

[John Pye (jdpipe)]

Yes, I vote for a higher importance too. If the applications menu can't be reverted to its original state, then wine shouldn't change it in its first place, as it breaks the whole "uninstall" concept.

[elhoir (jfarroyo82)]

I am using Ubuntu 7.10 which places a Wine submenu under Application menu, where there also are Sound & Video, Office, Programming and so...

In that Wine menu there are every software that i install from Wine

But when i uninstall software, or remove .wine directory, those softwares are not removed from that Wine submenus

[Jonathan Thomas (echidnaman)]

Confirming here in Kubuntu 7.10.
Hooray for KMenu edit, though. :P

[Vitaliy-bugzilla (vitaliy-bugzilla)]

Confirming.

[Juan-lang (juan-lang)]

I agree with you that uninstalling a program, or wine, should remove the menu entries. Just removing the .wine directory really can't remove these entries, however.

[Austin English (austinenglish)]

Shouldn't this be up to the distribution to handle?

[elhoir (jfarroyo82)]

(In reply to comment #3)
> I agree with you that uninstalling a program, or wine, should remove the menu
> entries. Just removing the .wine directory really can't remove these entries,
> however.
>

i think it can, since wine loads its content from the local directory of each user

it would be just a redirection of pointers, i think so...

[Brandontheninja (brandontheninja)]

Okay, I just figured out if you go to ~/.local/share/applications and delete 'wine', it will remove those entries from the Applications menu.

[elhoir (jfarroyo82)]

(In reply to comment #6)
> Okay, I just figured out if you go to ~/.local/share/applications and delete
> 'wine', it will remove those entries from the Applications menu.
>

i dont think that solution is fine, since that file is shared with all users, and we only want to delete our wine programs file menu, not others one.

[Vitaliy-bugzilla (vitaliy-bugzilla)]

(In reply to comment #7)
"~" means your home directory. So no you removing only your [user] links, not some one else's. You can more that directory and see what will happen. But it's more then just that directory. See FAQ on Wine's wiki for more details.

[Scott Ritchie (scottritchie)]

Is the issue that Wine simply doesn't implement the "uninstall this shortcut" method in Windows uninstallers? Or do Windows uninstallers rely on Windows keeping track of what shortcuts it installed and doing it for them?

In the latter case, we should be keeping a cache somewhere of the shortcuts Wine has created so we can uninstall applications cleanly.

[eldhaber_unit (eldhaber-unit)]

Ayus 'to ah! Thank you!

----- Original Message ----
From: Scott Ritchie <email address hidden>
To: <email address hidden>
Sent: Saturday, November 17, 2007 8:26:32 AM
Subject: [Bug 116080] Re: Incomplete uninstall of wine applications

** Bug watch added: Wine Bugzilla #10277
   http://bugs.winehq.org/show_bug.cgi?id=10277

** Also affects: wine via
   http://bugs.winehq.org/show_bug.cgi?id=10277
   Importance: Unknown
       Status: Unknown

--
Incomplete uninstall of wine applications
https://bugs.launchpad.net/bugs/116080
You received this bug notification because you are a direct subscriber
of a duplicate bug.

      ____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

[Damjan Jovanovic (damjan-jov)]

The freedesktop.org menus are the most complex out of all operating systems out there, and wine goes through a laborious process to make them.

Removing them is not simple. I believe wine does remove the .lnk files in ~/.wine/drive_c/windows/start menu and such, but the mapping between .lnk files and freedesktop menus is currently one-way.

A while back I thought up a scheme where explorer monitors the .lnk menus and the freedesktop menus and syncs them in real-time. But there are more problems, like if you delete a freedesktop menu it will be recreated as long as the .lnk file is there, unless you keep another list of created menus and don't create a freedesktop menu twice, but you have to keep track of .lnk deletions and remove from that list...

Yes, it's an incredible amount of work.

[Dan Kegel (dank)]

This affects lots of apps. Let's fix it for wine-1.2.

[Andreas Braml (a-strich-b)]

From the Wine FAQ at http://wiki.winehq.org/FAQ#head-9893ae50079ca7a959258f0bc9a17aaf2e69b391

<quote>The uninstaller does not remove menu entries. To remove all Wine created menu entries run the following commands
rm -f $HOME/.config/menus/applications-merged/wine*
rm -rf $HOME/.local/share/applications/wine
rm -f $HOME/.local/share/desktop-directories/wine*
rm -f $HOME/.local/share/icons/????_*.xpm
</quote>

[Austin English (austinenglish)]

*** Bug 8717 has been marked as a duplicate of this bug. ***

[Ambro (ambro)]

Would it be possible for Wine to keep it's own database somewhere inside ~/.wine and just link to is some way? The database could be linked to if the user adds it to XDG_DATA_DIRS, but that would be hard to do in a uniform way and changes would not be instant. Or is there some better way?

[Vincent Povirk (madewokherd)]

Shouldn't using the TryExec setting to link the menu shortcuts to their .lnk files solve this problem? From reading the spec, it seems like that should prevent the shortcuts from being displayed (even though files are still present) when .lnk files go away.

[Vincent Povirk (madewokherd)]

It's no good. The latest version of the spec says that the entry can be ignored if the file TryExec points to is not executable, which .lnk files are not.

TryExec ALMOST does what we need without requiring something crazy in Wine, and GNOME happens to implement it in a way that makes it work.. on GNOME at least, for now. It's so close I'm tempted to ask them to add a new field for non-executables.

[Vincent Povirk (madewokherd)]

Created an attachment (id=13315)
proof of concept patch

This is a rough attempt using the TryExec approach. Some issues:
* We have to chmod +x the .lnk file, which is sort of hacky.
* GNOME apparently expects the TryExec field to be strictly escaped (spaces replaced with \s and all).
* GNOME does not notice immediately when .lnk files are removed. I had to restart gnome-panel before it would see the changes.

I've not tested with any other desktop environments.

The advantage over some monitoring and/or syncing approach is that this is much simpler to implement and will hide the links if ~/.wine is removed.

[Austin English (austinenglish)]

*** Bug 13874 has been marked as a duplicate of this bug. ***

[Vincent Povirk (madewokherd)]

We could also create some new field in the .desktop files, e.g. X-Wine-Lnkfile, so that a process could periodically delete .desktop files whose .lnk files no longer exist. This is like the syncing approach except that it does not require the creation of some new "database" so would be easier to implement.

There is still the problem of deciding when to run this process.

[Ambro (ambro)]

But how does wine create a shortcut in the first place?
I guess there is a hook somewhere so that when an app writes a .lnk, some code is called that reads it and creates the appropriate freedesktop shortcut.
If so, I don't see why it couldn't be done the other way as well. When creating a freedesktop shortcut, wine should map the source .lnk to the files that were created for the freedesktop shortcut, most probably in the registry. Then add another hook to the delete function, and if the file being deleted is a .lnk, look it up in the registry and delete all parts of the freedesktop shortcut.

[Vincent Povirk (madewokherd)]

There's no hook. Windows has API for creating links (IShellLink), and Wine creates .desktop files when they are saved.

[Ambro (ambro)]

But who cares?
As I said, make wineshelllink map the shortcut to the files created in the registry. Then create another progam, such as "wineshelldelete", that is passed the location of the .lnk (existent or not), that would delete all the shortcut files associated with it. Finally, add a hook in the delete function to run wineshelldelete if the file ends in .lnk. Such a hook would really be no problem and would cause no performance problems.

[Thesource-mail (thesource-mail)]

Connecting .lnk files to .desktop ones is a bad idea. Why wine creates .lnk files in the first place? They are useless in linux and I don't want to see this garbage on my desktop. We need some other way of handling launchers. Using registry perhaps.

[Ambro (ambro)]

It's a fact that Windows deletes shortcuts by deleting .lnk files.
Yes, there would be a problem with desktop shortcuts specifically, becouse Wine tends to delete them, so the uninstallers might check if they still exist before calling "delete" on them. But this is no problem for the start menu, as the .lnk files reside in private folders which are invisible to the user. Actually, wine could keep desktop shortcuts in a private folder as well and avoid the hassle with deleting them.

For my plan to work, each shortcut should have independent .menu files.
Currently, when wineshelllink is adding a shortcut to an existing menu, it overwrites the corresponding .menu file and automatically adds all prevous menu entries to the new one. This is problematic, becouse when deleting a shortcut, wine would have to actually parse the menu file and remove only the shortcut's entry from it (<FileName>).
So the idea is that when a shortcut is being created, only new files would be added to the xdg database. This way deleting them would cause no harm to other menu entries.
I've tried splitting a .menu file with multiple entries in parts so that each one has just one <Filename> entry, and KDE merges the entries properly. I'm modifying wineshellink right now to do this.

[Ambro (ambro)]

Created an attachment (id=14602)
wineshellink seperate wineprefixes, independent files, record created files

This patch does the following:
- It changes the way files in the database are created so that they can be safely deleted when deleting a shortcut.
- It completly seperates wine prefixes when adding shortcuts to the start menu (different root Wine folders). This is required becouse all management would be local to a single wine instance.
- Maked wineshellink record all files created to $WINEPREFIX/shortcuts. Every file there represents a shortcut created and contains the list of paths in xdg trees. Every file is prefixed with "p:" (private) or "s:" (shared) - if it is shared, it can only be deleted once no other shortcut lists it as shared.

[Ambro (ambro)]

Created an attachment (id=14603)
wineshellunlink - removes created shortcuts

This is a shell script that removes a specific shortcut created with my version of wineshelllink. It should be used the same way as wineshelllink is, but only the --menu, --desktop and --link options.

Example, if a shortcut was created this way:
wineshelllink --menu --link 'Programs/MyApp/LaynchMyApp' --icon '/some/icon.xpm' --path '/home/user/.wine/dosdevices/c:/MyApp/MyApp.exe'

you can remove it by calling
wineshellunlink --menu --link 'Programs/MyApp/LaynchMyApp'

[Ambro (ambro)]

Created an attachment (id=14623)
wineshellink seperate wineprefixes, independent files, record created files

[Ambro (ambro)]

Created an attachment (id=14624)
wineshellunlink - removes created shortcuts

[Ambro (ambro)]

Created an attachment (id=14625)
winemenubuilder - work with previous patches, add scalling for removed .lnk files

[Ambro (ambro)]

The three patches I have just attached together provide you the ability to update the xdg database and remove shortcuts whose .lnk files have been removed using the command "winemenubuilder -s".
It will only work for shortcuts created using the above patches.
NOTE: wine tends to use "wineshelllink" from $PATH. Make sure wine is using my version of wineshelllink.

How it works:
- wineshellink records created files to $WINEPREFIX/shortcuts
- winemenubuilder records the .lnk locations of new shortcuts to HKCU/Wine/Software/WineMenuBuilder/Shortcuts.
- "winemenubuilder -s" scans the registry for .lnk files, calls wineshellunlink on nonexistent .lnk files, and removes their registry entries

Right now, "winemenubuilder -s" it will only work good for menu shortcuts, and will automatically delete all recorded desktop shortcuts, as wine deletes their source .lnk files.

[Ravichandra R (ravichandrra)]

Thanks it worked for me.

[Vitaliy-bugzilla (vitaliy-bugzilla)]

*** Bug 14385 has been marked as a duplicate of this bug. ***

[Ambro (ambro)]

Once the .lnk files are linked to the menu entries (example my previous patches), Wine could just sync the menu on startup (remove entries whose .lnk files no longer exist, in case the user removed them), and then use filesystem modification notification to monitor their removal while Wine is running (inotify, whatever it is). This would be a much saner method than adding a hook to detect delections.

[Ambro (ambro)]

Created an attachment (id=14895)
lnk file watcher plus my previous modifications

I've written some code to monitor .lnk files that are recorded to the registry. Right now I've added it do winemenubuilder because it has all the functions I need. This patch also includes all my previous modifications.

To try it out, first make sure my versions of wineshelllink and wineshellunlink are the first in PATH, and make sure wineshelllink is executable. After creating some start menu shortcuts, refresh your desktop so you see them (kde: kbuildsycoca). Then run "winemenubuilder -d" and leave it running. Now every time you delete a .lnk file from "c:\windows\profiles\all users\start menu", its menu entry will be removed. Again refresh the desktop to see the change.

The code could probably be added to explorer to avoid creating a new process. Anyway, what do you think about my approach?

[Ambro (ambro)]

Created an attachment (id=14896)
mailslot async fix

this patch is also required, it fixes some Wine bug I have stumbled on

[Ambro (ambro)]

Created an attachment (id=14897)
lnk file watcher plus my previous modifications

previous patch didn't compile ...

[cr0ybot (mastercory13)]

I didn't want to take out ALL of the menu items from Wine, so I went into the above mentioned directories and manually deleted the files/folders. I wish that for every app Wine installs, it would keep track of these items so that they could be uninstalled automatically.

[John Pye (jdpipe)]

Presumably this thing is working by creating .desktop files in response to files that are created in the equivalent Windows/wine path eg ~/.wine/drive_c/Windows/Start Menu or whereever that place is in Wine.

http://en.wikipedia.org/wiki/Start_menu#Technical_details

It should be possible to delete all these *.desktop files as directed above and then to recreate them. Wine needs to provide a script that does this periodically, perhaps.

[John Pye (jdpipe)]

Actually, looks like a patch has been proposed now over in wine..

[Scott Ritchie (scottritchie)]

This is an upstream bug so I'm marking it the same priority as the other upstream Wine bugs on launchpad.

[Damjan Jovanovic (damjan-jov)]

Hello Ambro, Vincent

Are you ever going to submit your patches to the wine-patches mailing list? And are you actually working on this bug?

If not, I'd like to take it over soon.

[Vincent Povirk (madewokherd)]

I'm not actively working on this bug right now. The patch I attached is not a good solution to this problem. It's an abuse of the TryExec field, and it doesn't work very well at all.

Now that wineshelllink is dead (good job killing it btw :), I am thinking about trying to add an X-Wine-LnkFile field to Wine-generated .desktop files and some sort of command to remove dead links. I don't have a clean path to a real fix, and there's no telling when I'll get to doing even that much.

I won't mind if you take this over, especially if you have a plan that might work.

[Ambro (ambro)]

I'm willing to work on this, but it seemed to me that nobody is really interested. So yes, I'll try to clean them up and submit them soon.

[Damjan Jovanovic (damjan-jov)]

Actually 10 votes + 38 comments is more than lack of interest. It's just that nobody looks at patches in Bugzilla.

Also, some hints from my personal experience of weeks of wrestling winemenubuilder patches into the tree:

Do not use a shell script. Alexandre was unwilling to commit a patch to winemenubuilder for .url files, until I sent a patch to delete wineshelllink. Your patch has no chance if you use a wineshellunlink script.

winemenubuilder has changed since last you looked at it, some of the functions you used no longer exist.

You should handle .url files as well as .lnk - currently you don't.

Alexandre doesn't like the Find*ChangeNotification*() functions, and says they aren't available on all systems and should only be used as a hint, you need to poll for file changes as well.

Comments starting with // aren't allowed, use /* */.

Anyway, thank you, good luck - and hurry up :-).

[Thesource-mail (thesource-mail)]

Removing links on uninstall is good, but adding them on install is broken in 1.1.9 in Fedora 10. .lnk file are created, but not .desktop ones.

[Thesource-mail (thesource-mail)]

Hm. Looks like only menu entries are created, but not desktop launchers.

[Ambro (ambro)]

I've already written something relatively functional. I've patched winemenubuilder to record created shortcuts (.lnk) to registry, along with some info. Then I've written a service which watches these files, and when it finds a nonexistent .lnk file, it removes the associated shortcuts on the user's desktop.

But there is a small problem. If the application installs a user-local desktop shortcut (~/.wine/windows/profiles/<user>/Desktop, which points to ~/Desktop), the .lnk file is of course visible on the desktop, along with the real shortcut (this can be seen without my patch).
Because the .lnk files annoy users, they will delete them, which will make my service remove the real shortcut as well.
I see two possible things to do:
- Don't attempt to record user-local desktop shortcuts to the registry. This way, they will never be removed.
- Don't point the Desktop folder (~/.wine/windows/profiles/<user>/Desktop) to the real desktop folder (~/Desktop). This way, removal will work, and the user will not be annoyed, but I'm afraid some apps use the Desktop folder for things other than shortcuts (e.g. Firefox saves downloads to desktop by default).

Does anyone see a better solution?

BTW, URLs are not implemented yet.

[Ambro (ambro)]

Created an attachment (id=17561)
shortcut watcher service

Here is the current state if anyone wants to test it; make sure to run "tools/make_makefiles && autoconf" and reconfigure.

[Ambro (ambro)]

About supporting URL files, can someone point me to a program that actually installs them? I've tried like 10 programs and those that do install URLs really create a .lnk that points to the .url somewhere.

[Vincent Povirk (madewokherd)]

You will probably need to break this into smaller patches before you send it in (not that there's any need to do it now), and I don't think you need to include the menu removal if it still doesn't work by that time. Just removing the shortcuts would be a large improvement, and usually empty menus will be invisible.

The separate .lnk and .desktop files on desktop shortcuts is a separate problem that you don't have to solve. It's been suggested that we should teach desktop environments to use the .lnk files so that .desktop files aren't needed, but we would need a way to store the wine prefix.

[Damjan Jovanovic (damjan-jov)]

Ambro, in dlls/shdocvw/intshcut.c, I've documented a program that installs .url files, one on the desktop, one in the menus.

[WanderingVillager (ovek)]

Forwarded Debian bug #507863 here.

[Dmitry-codeweavers (dmitry-codeweavers)]

*** Bug 17315 has been marked as a duplicate of this bug. ***

[Steve Dodier-Lazaro (sidi)]

By the way, gold_Single, you can get your divx movies to run in Totem if you install ubuntu-restricted-extras.

See : https://help.ubuntu.com/community/RestrictedFormats/ and https://help.ubuntu.com/9.04/musicvideophotos/C/video.html#video-badformats and https://help.ubuntu.com/9.04/musicvideophotos/C/video.html#video-badformats

Hope it helps.

[Scott Ritchie (scottritchie)]

By the way, the XDG-Dirs spec: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Would it be unreasonable to simply store the menu in the .wine folder and just add an extra base dir for XDG to look in?

[Dan Kegel (dank)]

It would require a change in the spec, and then
Gnome, KDE, and everybody else would have to implement
the change. That's reasonable in principle, but very slow
unless you happen to have a hotline to guys
in Gnome and KDE that can speed up consensus. Then
it would only take six months or so.

[Dylan Taylor (dylanmtaylor)]

This is probably one of THE most annoying bugs in Wine. The only solution I can think of is to have the entire program menu deleted every time something is added or removed, and then have it dynamically generated from a database of some sort that would be stored within the .wine folder. Although that would prove to be difficult to implement.

[elhoir (jfarroyo82)]

i guess you really HATE me :-)

[Damjan Jovanovic (damjan-jov)]

Vincent, Ambro: you've had your chance. Now I'm taking over.

javier: sorry to take so long, I'll try to fix it quickly.

[Damjan Jovanovic (damjan-jov)]

Created an attachment (id=21774)
log where freedesktop files go and provide an option to delete them

With this patch applied, freedesktop menus that winemenubuilder creates are logged to the registry, and when you delete the .lnk files and run "wine winemenubuilder -r" the corresponding freedesktop menus disappear.

Your menus generated before this patch was in effect can't be removed.

Also you have to run "wine winemenubuilder -r" manually, that will be done automatically in the future.

Patch has already been posted to wine-patches for review.

[Removed by request (removed1836289)]

(In reply to comment #54)
> Created an attachment (id=21774) [details]
> log where freedesktop files go and provide an option to delete them
>
> With this patch applied, freedesktop menus that winemenubuilder creates are
> logged to the registry, and when you delete the .lnk files and run "wine
> winemenubuilder -r" the corresponding freedesktop menus disappear.
>
> Your menus generated before this patch was in effect can't be removed.
>
> Also you have to run "wine winemenubuilder -r" manually, that will be done
> automatically in the future.
>
> Patch has already been posted to wine-patches for review.

Patch was committed.
http://source.winehq.org/git/wine.git//wine.git?a=commitdiff;h=267858b4c2484aa1905790140b0c962c12dcbb36

[Damjan Jovanovic (damjan-jov)]

With my 2 patches just committed to the lastest git:

http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d42982a1b0ae0d1d861

http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c5bb26cfc1fde96

I am tempted to close this bug, because menu deletion now works - but it's only preformed on Wine startup, and only on menus created with Wine >= 1.1.24 (maybe the version is a little earlier).

The latter problem is hard to fix and probably won't be (you'll have to delete menus made with older Wine versions manually), but the fix for the former is another patch I sent in and wasn't accepted.

So a few more days for that last patch to go in and then I'll close this bug.

You can expect this to fully work with Wine 1.1.25.

[Damjan Jovanovic (damjan-jov)]

Alexandre Julliard tells me that the menu deletion while Wine is running "would have to be some sort of [Windows NT] service, but yes i expect startup only is good enough for now".

Hence, no patch to delete menus while Wine is running at this time.

Resolving fixed.

[Scott Ritchie (scottritchie)]

Why would a service be needed? All I really want is some way to manually tell Wine "check the menu again" - then we could put that code into Wine Uninstaller and Gnome-App-Install (a frontend to wine uninstaller that I'm working on). That way if Wine is still running while they uninstall an app everything would be handled fine.

That would cover a very large use case right there.

[Damjan Jovanovic (damjan-jov)]

Scott, you can manually run "wine winemenubuilder -r" to uninstall menus whenever you want to (eg. after an app is uninstalled). "wine winemenubuilder -a -r" is even better since it will clean up file type associations too.

And while you're here: even though I use Ubuntu, I hope all these changes you are making to better integrate Wine into the desktop are cross-distro, and done in Wine itself when possible.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 1.1.25.

[Ken Sharp (kennybobs)]

The shortcuts are removed, the folders are not.
Under Windows, the folders are removed also.
Reopen or is that bit a wontfix?

[Vincent Povirk (madewokherd)]

It doesn't make sense to remove the folders. They're likely to be used in a different wine prefix, and menu implementations tend to not show empty folders anyway.

[Ken Sharp (kennybobs)]

Why would I have the same program in two different wineprefixes?
With that in mind, if I do, the shortcut would only point to one wineprefix anyway, which, when removed, would make the folder again redundant.

Removing the shortcut is only half the problem. Users still have to go in, find the directory, and delete it, which is what was happening anyway.

[Ken Sharp (kennybobs)]

*** Bug 19213 has been marked as a duplicate of this bug. ***

[Vitaliy-bugzilla (vitaliy-bugzilla)]

*** Bug 19213 has been marked as a duplicate of this bug. ***

[Ansus (neptunia)]

I experience the same problem with Tropico 3 and Wine 1.1.39.

[Vincent Povirk (madewokherd)]

You should probably open a new bug for that. Since this is a general issue and it should be fixed, it's likely you're seeing a more narrow problem.

[Russian redneck (otaku-8)]

the same bug in wine 1.4-rc1, ubuntu 11.10
wine winemenubuilder -a -r doesn't help

[Rolf Leggewie (r0lf)]

this was apparently fixed upstream