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