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,
Well, just a feeling, but I have always been irritated about that the .lnk files are not real symlinks.
Wine is not only supposed to be as good as Windows but also better if possible.
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
Yes. However you could have a drive table like
echo /windows-c-drive > /proc/windows/drive/c echo /windows-d-drive > /proc/windows/drive/d
So the kernel could do the look up.
BTW this would also means that Wine could read /proc/windows/drive and map the drives.
- all UNC symlinks except those to \localhost. But don't these paths
have a drive letter too?
Even worse they have the first part after \localhost should be the name of the share so that means that we need to have a series of /proc/windows/share directories or something as well...
- I guess he would also ignore the command line options
specified in shortcuts to executables
- and also the current directory
Hmm. Well, that is a problem as well. Perhaps you could link to some sort of autogenerated shell script in /proc/windows/links say you access /mnt/c/test.lnk and you get a shell script in /proc/windows/links/mnt/c/test.lnk or something that /mnt/c/test.lnk symlinks to.
- 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.
I don't consider this a problem.
However solving the other problem is probably to ugly eventhough they are solvable in some meaning.
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.
Indeed. It would be better if it was generalized somehow. Hmm...
- 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).
Doing it is not the problem. Accepting the overhead and the ugly hack is the real problem...
The other issue is that this workaround is not implemented yet so we may get stuck in a bad place for a while.
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.
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.
As the default behavior I also oppose it.
Unfortunely I very much fear that I won't be possible to do it in an acceptable way at all...