RE: Linux patch for supporting shortcuts and symlinks on VFAT
On Tue, 11 Jun 2002, Patrik Stridvall wrote:
I notice that I patch have been posted to the linux-kernel that might be of intrest to us.
vfat patch for shortcut display as symlinks for 2.4.18 http://marc.theaimsgroup.com/?l=linux-kernel&m=102358795411222&w=2
It seem that at least some people are against it inclusion so I wonder whether we should support inclusion of the patch or not.
I'm personally a little doubtful that it is a good idea...
I think it's a bad idea. The reason is that the VFAT driver is the wrong abstraction layer to support the '.lnk' files:
Probably. The more I think about the more I worry about the consequences. However it would be nice be nice to handle .lnk files as symlinks somehow.
* on Windows if you open("foo.lnk") you get the .lnk files, not the file it 'points' to. On Linux you would get the file it points to instead which is a different behavior.
True. However we could check if the extension is .lnk in OpenFile as friends and then call special funcitons like readlink to read the file. But it probably would be a too ugly hack to be worth it.
* Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if such support is added in the Linux kernel, it should be added to all of the above filesystems. And then there is no reason not to add it to ext2, NFS, etc!
True. The feature should probably be at file system independant layer, if anywhere.
This would also hurt Wine as:
* it would prevent us from reading the information in the '.lnk' file... at least for 'supported' '.lnk' files
Well, as I said above, we can read them with readlink and friends.
* it's not entirely clear to me what they do with unsupported '.lnk' files. Are they just dead symlinks or can one read their contents? In the first case Wine is SOL again, and in the latter case we'll have to play games to know which kind we got.
As I said, you always can read a symlinks content with readlink.
* it was suggested to implement a hack to let Wine access the '.lnk' data. Why implement a hack which is going to be Linux specific when doing nothing works just fine and on any Unix system?
True.
* making it a default option does not help Wine at all. Then we have to keep telling users that they have to modify their fstab if they want Wine to work.
Yes, that is a problem. See below.
The right level to implement symlink support is:
* in Wine. Of course!
:-)
* in an LD_PRELOAD library. Then they would work for all filesystems, be selectable on a per-user or even per-process basis. Of course it would most likely not work with Wine (ld_preload libraries seldom do).
* as an option in the KDE/Gnome file browsers. That's the layer which seems closest to the Windows shell 'layer'.
True. Anyway, the big question seem to be whether we should oppose the patch or not. It might could trouble for Wine is such a feature exists some user might active it so we have to handle that case. BTW. I just though of another thing. Perhaps we should support the opposite. Translate existing symlinks to .lnk files?
This looks like it could be the next 'unhide' thing. hmmm, probably, people not subscribed to linux-kernel missed the 'unhide' issue. See: * Jeremy White - isofs unhide option: troubles with Wine http://marc.theaimsgroup.com/?l=linux-kernel&m=102230123607864&w=2
I basicly agree with your opinion. The hidden attribute is metadata meant as advice for the application not something the operating system should concern itself.
On Tue, 11 Jun 2002, Patrik Stridvall wrote: [...]
However it would be nice be nice to handle .lnk files as symlinks somehow.
I'm not sure this is very useful, especially since few symlinks will be supported in any case. For instance in his proposal he ignores: * all symlinks to absolute paths. That would be pretty much all symlinks created under windows * all UNC symlinks except those to \\localhost. But don't these paths have a drive letter too? * I guess he would also ignore the command line options specified in shortcuts to executables * and also the current directory * and the icon of course. Which then means tools like konqueror or nautilus cannot extract the icon either unless they make use of the proposed ioctl hack. And if the goal is to be able to create symlinks on a filesystem that does not support them, I believe the right way to do so would be to have a module sit on top of the file system that would do things ala umsdos. This would for instance allow one to also get things like ownership, file permissions, device files, socket files, etc. And if you are going to use a VFAT filesystem as a regular Unix filesystem, having permissions at least while in Linux seems like it would be a very good thing.
* on Windows if you open("foo.lnk") you get the .lnk files, not the file it 'points' to. On Linux you would get the file it points to instead which is a different behavior.
True. However we could check if the extension is .lnk in OpenFile as friends and then call special funcitons like readlink to read the file. But it probably would be a too ugly hack to be worth it.
Yes that's the soluti^H^H^H^H ugly hack that was suggested as a workaround. It would probably involve an ioctl of some sort though here we are talking about reading the content of a file, not just a couple of metadata bits, not sure how ioctls handle such things (maybe that's not a problem, I'm not very familiar with ioctls). The other issue is that this workaround is not implemented yet so we may get stuck in a bad place for a while. [...]
Anyway, the big question seem to be whether we should oppose the patch or not. It might could trouble for Wine is such a feature exists some user might active it so we have to handle that case.
It is proposed as the default behavior. This means it would likely end up as the default in most distributions, so many users will be hit by it even if they did not activate it. I definitely oppose it. I believe it is not only harmful to Wine, but also the wrong thing for Linux. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
participants (2)
-
Francois Gouget -
Patrik Stridvall