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