Linux patch for supporting shortcuts and symlinks on VFAT

[Patrik Stridvall]

> 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.