Linux patch for supporting shortcuts and symlinks on VFAT

[Francois Gouget]

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 at free.fr        http://fgouget.free.fr/
     The software said it requires Win95 or better, so I installed Linux.