GNOME Bugzilla – Bug 47894
Add ability to handle Windows .lnk files
Last modified: 2021-06-18 15:29:14 UTC
Especially for those migrating from Windows to Linux, there are many cases where it would be nice if Nautilus handled Windows links as though they were real links. ------- Additional Comments From darin@bentspoon.com 2001-03-26 19:20:36 ---- It would be easy to add a third kind of link to the code that handles GMC links and Nautilus links. ------- Additional Comments From bfrantzda@hmc.edu 2001-03-27 11:15:55 ---- A quick search of google gave this link: http://www.wotsit.org/download.asp?f=lnk It's DOS C code to produce a windows link. ------- Additional Comments From snickell@stanford.edu 2001-07-23 00:34:03 ---- Taking bugs previously assigned to Pavel, assigning them to myself. Will parse them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:31 -------
Changing to "old" target milestone for all bugs laying around with no milestone set.
Should this just be moved to either gnome-vfs or gnome-vfs-extras?
I'm thinking this probably belongs in gnome-vfs. Feel free to change the package again if I'm wrong.
How exactly would you expect this to work? if my .lnk file points to C:\Program Files\foo\foo.exe what am I supposed to do? I don't think there is an easy way to define any method of operation for this. If I have a .lnk file I probably am using wine or something similar so I would probably just want it to handle it instead.
Reassigning from GnomeVFS to Nautilus.
FWIW, I am only interested in the special case of links to UNC paths. I think this particular case should be easier to implement than the general case. For example, if foo.lnk points to \\machine12\path\to\some\file.txt, I would like Nautilus to treat it as though it were a link to smb://machine12/path/to/some/file.txt.
When accessing a Windows-installation or files copied from one, it's always convenient and helpful to be able to view the lnk-information at least. So that should be shown in the properties of the lnk-file. CPP source code for reading and lnk file from the KDE project: http://websvn.kde.org/branches/KDE/3.3/kdeaddons/kfile-plugins/lnk/read_lnk.cpp?view=markup For actually using lnk-files, the lnkforward KDE-application does this by mapping drives as arguments. For example: lnkforward --map c=/mnt/windows --map d=/mnt/windows-data /mnt/windows/notepad.lnk Or something similar, maybe that wasn't the exact syntax.
If the lnk contains a relative path or remote path, it can be followed, right? It's only the absolute path that is unknown. We should also support launching the browser from .URL files, which are rather trivial: [InternetShortcut] URL=http://www.example.com/webpage.html http://www.cyanwerks.com/file-format-url.html
There is also the question - should the .lst extension be reserved for links produced by windows systems? Otherswise any piece of software could reasonably begin using this extension. Just something to keep in mind.
(In reply to comment #9) > There is also the question - should the .lst extension be reserved for links > produced by windows systems? Otherswise any piece of software could reasonably > begin using this extension. Just something to keep in mind. > What is the format of .lst files? I wrote a script for launching .url files: https://bugs.launchpad.net/ubuntu/+source/mime-support/+bug/185165 This probably belongs in a different bug, though. Launching any of these files doesn't really have anything to do with Nautilus, I guess. Should we change the product to gnome-mime-data or something?
I’d just like to say that this feature would be very appreciated here, especially in the variant that opens UNC paths. I think some Code could be borrowed from KDE here.
FWIW: There is lnk-parse-1.0.pl from http://jafat.sourceforge.net/files.html which parses the LNK file or http://bitbucket.org/haypo/hachoir/wiki/hachoir-urwid. See also discussions on http://bugs.kde.org/show_bug.cgi?id=85348 or https://bugs.launchpad.net/kdebase/+bug/76326.
*** Bug 336177 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.