Wine is creating .lnk files in addition to desktop shortcuts

It's great that Wine is noticing that a .lnk file were written by
IID_IPersistFile->Save and is creating a Linux compatibe program icon on the
desktop. But why the .lnk file is also appearing on the desktop, which has (in
my opinion) no use.

Only a cosmetic thing

Thanks

Markus

this affects http://www.emtec.com/zoc during setup phase

see also bug 5631.

I think, wine should use a separate directory for the desktop or there should
be a way to disable such integrations before building wine. For example, I
want to use a kicker menu extension for KDE which shows the start menu and
some other dirs and do not want wine to try integrating itself to window
manager.

I have seen this too.
AnzioWin / AnzioLite : http://www.anzio.com (terminal emulator)
WinRAR : http://www.rarlab.com (compression & archiving util)

SuSE 10.1 & 10.2 at least
slosh:~ # wine --version
Wine 0.9.24

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

Confirming. As far as I can tell, if you run winecfg and go to Desktop
Integration tab, and click on Desktop under shell folders, and uncheck the Link
To box, then only the Linux compatible icon is put on the Desktop, while the
.lnk file is put into the Desktop folder in wine's drive_c/windows/profiles

Hm, sounds like Wine is doing what it should. But is it useful to place
the .lnk file also the the Linux desktop, when there is definitely no use for
it? So maybe a exception for .lnk files would be useful...

I suggested that, but unfortunately the developers can't reproduce this issue as
far as I can tell. Actually if you have binfmt_misc setup properly on your
system, you can use the .lnk files. So IMHO, wine should just drop .desktop
icon creation and change the icon for the .lnk files.

Looking back into this, I'd like to correct what I said in my last message..

Don't drop .desktop file creation.

The reason wine puts both the Freedesktop icon and the Window icon is due to
winecfg having the windows desktop set to the same location as the Linux
desktop (~/Desktop).. Either we need to change the default location to
somewhere else, or (better yet) we should intercept .lnk file creation and
put .lnk files to ~/.wine/drive_c/windows/Desktop while everything else goes
to the linux desktop...

Still present.

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

Still present.

still presents

Isn't that fixed in WINE 1.1.25 ?

Looks like it.

It's NOT fixed. Just installed Trine demo using today's GIT and the bug is still present. How to reopen this bug?

(In reply to comment #16)
> It's NOT fixed. Just installed Trine demo using today's GIT and the bug is
> still present. How to reopen this bug?

Yeah, it appears to depend on the program. Firefox doesn't have the problem anymore, but, e.g., CCleaner does.

If the program is creating .lnk files in some temp directory, then it's copying the file to the desktop I think this might be a WONTFIX.

Created attachment 22902
Wine 1.1.27 +file +menubuilder (2.2MB)

trace:file:CreateFileW L"C:\\users\\test\\Desktop\\Magic Workstation.lnk" GENERIC_READ GENERIC_WRITE creation 2 attributes 0x0

Magic Workstation (affected) doesn't appear to use a temp directory, and creates the .lnk directly on the desktop.

+file,+menubuilder attached for perusal.

Rather than going through this process of creating a ".desktop" file, couldn't Wine register a MIME type for the ".lnk" file and setup Wine to launch through the ".lnk" file directly?

Yes, but the .lnk files would not work correctly for prefixes other than the default. Also, the desktop environment would probably have to create a winelib process to thumbnail the .lnk files, which could be expensive.

(In reply to comment #21)
> Yes, but the .lnk files would not work correctly for prefixes other than the
> default. Also, the desktop environment would probably have to create a winelib
> process to thumbnail the .lnk files, which could be expensive.

Good points. While you could work around these issues pretty readily it's probably not really worth it.

It whould be good if links to programs was supported in the coming version of wine.

It's lame that the icon looks & works like a textdocument.

When you install stuff in Windows the icon has a picture so why not implement it?

Patches are more than welcome.

Bug duplicated before I read these reports. Wine 1.1.31. The app icon and .lnk on the desktop, and an item appeared in the Wine menu structure. App allowed me to log into my B&N account, then crashed. Thereafter, would crash without allowing me to log into my B&N account.

This behaviour happens with IMatch 3.6.0.90, too. See http://appdb.winehq.org/objectManager.php?sClass=version&iId=15969 for details.

Wine has 2 desktops: the user desktop under C:\users\user\Desktop, and the public desktop under C:\users\Public\Desktop.

Applications that install .lnk files to the public desktop end up putting those files under ~/.wine/drive_c/users/Public/Desktop, from which winemenubuilder generates a .desktop file in ~/Desktop. All is well.

But some applications (eg. WinRAR) want to install .lnk files to the user's desktop, which is ~/.wine/drive_c/users/user/Desktop, but that isn't a directory, it's just a symlink to ~/Desktop. So the .lnk file goes onto the real desktop instead of the hidden one.

The selection of where to save the .lnk happen in shell32's IShellLink's IPersistFile COM interface, before winemenubuilder is launched. By the time winemenubuilder runs, the .lnk file already exists in the wrong place.

It would be possible for winemenubuilder to move or delete the .lnk file after it generates the .desktop file, but then we'd lose track of the .lnk <-> .desktop mapping which winemenubuilder can do in order to delete .desktop files when the corresponding .lnk files are gone (because eg. the application was uninstalled). Some more intelligent Wine desktops <-> ~/Desktop synchronization might be necessary.

Perhaps we could move the .lnk's from the 'user' desktop to the 'public' desktop, which would keep it off the 'real' desktop, but also allow keeping track of it to remove the .desktop for later removal?

(In reply to comment #28)
> Perhaps we could move the .lnk's from the 'user' desktop to the 'public'
> desktop, which would keep it off the 'real' desktop, but also allow keeping
> track of it to remove the .desktop for later removal?

The application tells shell32 to write the .lnk file to a specific C:\path\to\file.lnk location and remembers that location. Any attempt to move or rename the .lnk after that - even to the other desktop - loses that file and stops the application from deleting it on uninstall.

The only thing I can think of that would fix this is to virtualize the filesystem - eg. use a FUSE module that merges ~/.wine/drive_c/users/user/Desktop with ~/Desktop when reading, but write .lnk files to ~/.wine/drive_c/users/user/Desktop and everything else to ~/Desktop.

> The application tells shell32 to write the .lnk file to a specific
> C:\path\to\file.lnk location and remembers that location. Any attempt to move
> or rename the .lnk after that - even to the other desktop - loses that file and
> stops the application from deleting it on uninstall.

so when some application want to write .lnk file to:
~/.wine/drive_c/users/user/Desktop
handle it and redirect to:
~/.wine/drive_c/users/Public/Desktop
and when uninstaller will want to delete it from:
~/.wine/drive_c/users/user/Desktop
handle again and redirect to:
~/.wine/drive_c/users/Public/Desktop

Can it work just like that?

(In reply to comment #30)
> > The application tells shell32 to write the .lnk file to a specific
> > C:\path\to\file.lnk location and remembers that location. Any attempt to move
> > or rename the .lnk after that - even to the other desktop - loses that file and
> > stops the application from deleting it on uninstall.
>
> so when some application want to write .lnk file to:
> ~/.wine/drive_c/users/user/Desktop
> handle it and redirect to:
> ~/.wine/drive_c/users/Public/Desktop
> and when uninstaller will want to delete it from:
> ~/.wine/drive_c/users/user/Desktop
> handle again and redirect to:
> ~/.wine/drive_c/users/Public/Desktop
>
> Can it work just like that?

If the application wants to write .lnk file to:
~/.wine/drive_c/users/user/Desktop
and Wine instead writes to:
~/.wine/drive_c/users/Public/Desktop
the application still thinks it wrote to:
~/.wine/drive_c/users/user/Desktop
and on uninstall tries to delete the .lnk from:
~/.wine/drive_c/users/user/Desktop
where it isn't.

Perhaps we can store the Wine prefix in the .lnk file somewhere. Then we'd write
a Unix tool that extracts the prefix and runs 'wine start <shortcut>.lnk' in it.

We'd register the tool with the native desktop as the handler for
application/x-win-lnk and stop writing separate .desktop files when writing
to the desktop folder.

That leaves the thumbnail issue. Presumably thumbnails are cached to mitigate
the performance issue? Alternatively we could have our own thumbnailer cache
the generated icons.

Another issue with this approach is that Gnome hides the .desktop extension
but not the .lnk extension, like Windows does.

(In reply to comment #32)
> Perhaps we can store the Wine prefix in the .lnk file somewhere.
You can't do that. Some dumb installers have "pre-packaged" .lnk files that are just copied into place.

Those are broken on Windows too, although differently. I recall that
Windows has a dialog to search or browse a missing shortcut target.
We could do something along those lines if we don't find the prefix.

(In reply to comment #33)
> (In reply to comment #32)
> > Perhaps we can store the Wine prefix in the .lnk file somewhere.
> You can't do that. Some dumb installers have "pre-packaged" .lnk files that are
> just copied into place.

Pre-packaged .lnk files that get just copied into place would bypass shell32's IShellLink's IPersistFile_Save, and winemenubuilder won't get invoked to build .desktop files. Such files also imply that you can't choose where to install the application, since that affects the .lnk contents?

We shouldn't store the Wine prefix in the .lnk file, it could go into some other settings database (maybe not the registry, since that's local to each Wine prefix), from where the tool that starts .lnk can look up which Wine to use.

At least we can patch Gnome and write a thumbnailer - it must be real fun and games to fix this on MacOS :-).

> We shouldn't store the Wine prefix in the .lnk file

Why not? It appears to an extensible format, see IShellLinkDataList.

What should be possible, is that Wine converts a .lnk to .desktop when a program copies it into any Desktop folder. When a program tries to move the 'lnk' away, the .desktop is converted back to .lnk. If a program tries to rename/delete a .lnk on the desktop, it is done with the .desktop file. When a program queries a list of files in the desktop folder, the .desktop files seem (to the Windows program) to be named .lnk.

Just an idea how to solve this problem.

Still happening with Wine 1.3.16 and SketchUp 8.0.4811

I tested this with Fedora 16 Beta+ with Wine 1.3.31 (Fedora's version) and Notepad++ 5.9.6. Both files appear.

Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1.
I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with new method of not showing the files. Is this a large issue any more (for certain D.E.)? Has this move changed ideology for .lnk files being a viewable issue?

(In reply to comment #40)
> Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1.
> I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with
> new method of not showing the files. Is this a large issue any more (for
> certain D.E.)? Has this move changed ideology for .lnk files being a viewable
> issue?

1. When the .lnk file is on the invisible desktop, we add a .desktop file on the visible desktop.
2. When the .lnk file is on the visible desktop, we add a custom thumbnail to that .lnk file.

Point 1 already works. Point 2 is difficult, since each desktop environment has its own way of adding custom thumbnails to files.

I wonder if the Portland project could add a desktop-independent tool for adding custom thumbnails to arbitrary files?

Oh and Gnome 3 / KDE 4 have dropped support for so many XDG standards that I have even less hope for this working properly everywhere nowdays.

(In reply to comment #29)
> (In reply to comment #28)
> > Perhaps we could move the .lnk's from the 'user' desktop to the 'public'
> > desktop, which would keep it off the 'real' desktop, but also allow keeping
> > track of it to remove the .desktop for later removal?
>
> The application tells shell32 to write the .lnk file to a specific
> C:\path\to\file.lnk location and remembers that location. Any attempt to move
> or rename the .lnk after that - even to the other desktop - loses that file and
> stops the application from deleting it on uninstall.
>
> The only thing I can think of that would fix this is to virtualize the
> filesystem - eg. use a FUSE module that merges
> ~/.wine/drive_c/users/user/Desktop with ~/Desktop when reading, but write .lnk
> files to ~/.wine/drive_c/users/user/Desktop and everything else to ~/Desktop.

I like the virtualized filesystem idea, but its probably not practical for wine itself to implement, moreso something for a separate project (winetricks?)

As for the link tracking, the same thing happens in Windows when one moves the .lnk file from their personal start menu folder or desktop to the public one. IMHO, it should just be considered expected behaviour for the links to be manually removed from the user's desktop when an app is uninstalled. That or do a forced check of the user's desktop for a .desktop file in the wine uninstaller tool, though I think the manual removal idea is better, personally.

As far as your comment on GNOME and KDE dropping support for XDG standards, that's just sad. They used to be the pinnacle of openness, and the decreasing support for those standards just shows the winds of change are not always good.

(In reply to comment #42)
> I like the virtualized filesystem idea, but its probably not practical for wine
> itself to implement, moreso something for a separate project (winetricks?)

Thinking further about the virtualized filesystem idea, it should, in theory, be possible to virtualize the filesystem without needing a fuse driver, if the user were to setup a single file that were to hold the filesystem, sort of like a VHD or an ISO. I like the ISO idea better, but perhaps something that's not associated with a read-only media would be more appropriate.

That way it could be mounted with the loopback driver already in the kernel and reads/writes would just take place to the mount point. It would make managing things easier because the user could create an fstab-like file for wine to read (or just do it in winecfg) to specify the mount point and path to the file containing wine's filesystem -- That's the one thing I've always disliked about wine was having the filesystem default to being under my home directory.

Rather, I dislike that it defaults to being in .wine under my home directory. I'd be OK with it being inside a hidden file, because it's a single file, rather than a whole folder that some tools (grep -R, find, etc) would then search through.

Also, if the filesystem is virtualized from inside of a single file, then the user's desktop can be an actual folder and wine can track links to that between it and the real ~/Desktop. In addition it solves a lot of issues with multiple users in the linux system wanting to share a single prefix (could move the prefix out of ~/.wine and into /home/.wine or /home/wine as well as allowing one to have and manage multiple prefixes from within winecfg could become easier)...

Upon installation, Notepad ++ put desktop .lnk and program icon on desktop. No big problem, just delete desktop.lnk and get on with it.

Its not a bug but feature. It allows to run Steam games in Crossover.

Still exist in wine1.6-rc4

Still present in wine-1.7.11-306-g8f289c8

Still present in Wine 1.7.20 (CentOS 6.5 32-bit - Command and Conquer 3 - Tiberium Wars demo)

Still the same as comment 1.

wine 1.7.22

Has something changed? I have installed some programs via 1.7.24 and I only see 1 desktop icon, no lnk file anymore.

Just installed Command and Conquer 3 Kane Edition with wine 1.7.18 (latest for Ubuntu 12.04 LTS?).
Here also a .lnk and a desktop shortcut have been created.

This is _NOT_ still present in Wine 1.9.5 with Fedora 23 using Notepad++ 6.9.

Will somebody please test this for me? I tried this with a virtual desktop and without a virtual desktop and could not reproduce this again. It could be a change in Notepad++, though.

This is _NOT_ still present in Wine 1.9.5 with Fedora 23 using Nightingale 1.12.1 (getnightingale.com).

(In reply to gat from comment #54)
> This is _NOT_ still present in Wine 1.9.5 with Fedora 23 using Nightingale
> 1.12.1 (getnightingale.com).

Well it's still an issue here. 1.9.6

Also windows had behaviour that .lnk files were links to actual files. Now wine is doing something very different.

Still present in Wine 3.0-rc2 and Staging 2.21.

Still present in Wine 6.22

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

I am only seeing Notepad++.desktop in ~/Desktop or /home/USERNAME/.wine/drive_c/users/USERNAME/Desktop.

I am using Fedora 37 with wine 7.20 (Staging) and npp++ v8.4.7 for 64 bits.