GNOME Bugzilla – Bug 163544
Cannot follow shortcuts (*.lnk files) to Windows directories
Last modified: 2018-05-02 14:06:42 UTC
recognize *.lnk as links and not as picture files Other information: I'm sorry for this report. I didn't really have time to check the whole bug-list. just look at this as a well meant input for improvement. LOW PRIORITY
Well, if this is meant as well-meant input, you should at least take the time to add enough information about the problem.
Please explain your problem or we will have to close this report as incomplete.
.lnk files are Win32's idea of symlinks. The file chooser displays them as normal files, and trying to open them results in a failure, even when they are pointing to an existing image file. This report should be reassigned to GTK+.
Links (or "shortcuts" as the .lnk files usually are called) are handled in the drag-and-drop code in gdk/win32. Presumably the file chooser or gtkfilesystemwin32 should be enhanced to follow shortcuts using similar code and returning the path to the shortcut target and not the shortcut itself, it a such is selected.
*** Bug 311807 has been marked as a duplicate of this bug. ***
*** Bug 340026 has been marked as a duplicate of this bug. ***
I don't understand why this bug is marked with minor severity. If I was unable to follow symlinks in linux would this be a "small feature"? This bug _breaks_ navigation and makes apps look broken. Comment #4 say there is already code to do this in gdk/win32.
The "small feature" (the value of the "Target milestone" field) describes how hard it is to fix this bug, and does not say anything about the bug's seriousness. I will upgrade the severity to "normal", though. If you want the bug to get fixed faster, feel free to submit a patch. I think you might be overestimating the seriousness of this bug. What shortcuts on a *typical* end-user machine is it that the *typical* end-user would want to follow in some GTK+ application?
Hi Tor, I hit a typical user that has "links" in the desktop to often used folders and "mounted shares". I needed to explain him why it wasn't working as usual. I myself use shorcuts to folders, like other users. I'll take a look if I've got some free time. Thanks!
See also bug #326956 which is about implementing this for desktop links as used in GNOME (no idea if KDE use the same syntax or not).
*** Bug 403843 has been marked as a duplicate of this bug. ***
*** Bug 433376 has been marked as a duplicate of this bug. ***
*** Bug 449002 has been marked as a duplicate of this bug. ***
About comment #7: > If I was unable to follow symlinks in linux would this be a "small feature"? That is not a fair comparison. Symlinks in Unix are very different from shortcuts in Windows. Symlinks are followed transparently by the operating system itself when passed to system calls. You have to explicitly use different system calls to manipulate the symlink itself or read where it points. Shortcuts on Windows are quite different. They are really just files (*.lnk) that happen to contain the pathname of another file (folder, usually) and must thus be handled explicitly in user level code.
Just FYI: What *is* more equivalent to symlinks are junctions. (Only for folders, though.) There is little support shipped with Windows to manipulate them, though. There is a command-line tool to create junctions available from sysinternals.com. Junctions work on a much lower level than .lnk files (shortcuts), and work fine with the GTK+ file selector. (For instance, mostly just for fun, I have a junction c:\home that points to c:\Documents and Settings.) Unfortunately because junctions are so "new" (reparse points were introduced in Windows 2000, I think, only like 7 or 8 years ago), few Windows tools recognize them and instead think a junction *is* the folder it points to. So for instance my virus scanner scans my home folder twice, first under \Documents and Settings, then under \home. Big deal. I guess also backup software can be fooled by them and back up stuff multiple times.
The main difference between Windows shortcuts (*.lnk) and UNIX symlinks is that the latter are handled transparently by the operating system. But on disk, both of them just contain text that represents the path name of the destination of the link. It's just that UNIX hides that from the applications and does the right thing automatically, while Windows doesn't. </useless_comment>
See bug 561494 for a patch that adds some form of shortcut handling. Might be good to test it out and report if it works as you expect.
*** Bug 565796 has been marked as a duplicate of this bug. ***
*** Bug 596644 has been marked as a duplicate of this bug. ***
Any news on fixing this? This bug/feature req is not specific to Win2k BTW, it's the same on XP. What happened to the patch mentioned earlier?
I don't see any news. Summary corrected. What patch do you mean?
Nevermind. http://msdn.microsoft.com/en-us/library/bb776891(VS.85).aspx Apparently you have to use IShellLink. Or support the binary format http://msdn.microsoft.com/en-us/library/dd871305(PROT.10).aspx There's probably a reason why other frameworks uses Windows' own file dialogs.
*** Bug 649913 has been marked as a duplicate of this bug. ***
If someone does get around to working on this, it would be nice to support Cygwin symlinks as well. See http://www.mail-archive.com/cygwin@cygwin.com/msg100310.html for a list of all the symlink formats that Cygwin supports.
I was wondering this the other day as well. Windows shell links ("shortcuts") may not be low-level as Unix style symbolic links are (Win32 still recognizes them as individual files; they are never displayed in the Folders panel of the Windows Explorer, and you can rename/copy them without affecting the original), however it is also true that almost every native Windows app uses the native Windows file dialog (which follows/dereferences them by default), the win32 GTK+ needs to be aware that these are not like other data files.
*** Bug 701531 has been marked as a duplicate of this bug. ***
*** Bug 704837 has been marked as a duplicate of this bug. ***
idem on Mac: Gimp is unable to open an alias (link file) as layer, as file itself, Gimp should be able to find the original file if the selected file is only an alias (link file)
i forgot: on Mac, when i use a right-click on an alias file, Gimp opens that the original. Same result like with right-click, when i use a shell script like: open -a Gimp quoted form of posix path of alias_file
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Yes, definitely still relevant. Modern Windows systems have a variety of means to link one location from another (see comment #15), but *.lnk files are still THE most common form that a regular Windows user has access to.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/242.