Re: Bug in builtin function abspath

[Eli Zaretskii]

> Date: Tue, 06 Jun 2006 16:18:47 +0200
> From: Alessandro Vesely <address@hidden>
> 
> >> And what about realpath?
> > 
> > The same, except that it should fail if the file or its parent
> > directory doesn't exist, and it should ``resolve links'', whatever
> > that may mean on Windows.
> 
> Hmm... it will be necessary to consider win9x/ME differently than
> win2k and later versions that have restricted symlink capability.

Do you mean the .lnk (a.k.a. shortcut) files?  If so, I wouldn't call
them symlinks, not even restricted ones.  As long as most file I/O
APIs don't follow links, we are better off behaving as if there are no
symlinks at all.

> With mount points one cannot reach "symlink/../not-in-cwd". To be
> consistent with that, we should first compute ".."'s and then fail.
> Correct?

Sorry, I don't follow: what mount points?

> Probably that's going to change again for Vista, see
> http://msdn.microsoft.com/library/en-us/fileio/fs/creating_symbolic_links.asp
> 
> Should I try a patch?

The best way to prepare for symlinks in Vista is to have a realpath
emulation somewhere in w32/ subdirectory.  Then we could define
HAVE_REALPATH in config.h.W32 and things will ``just work''.

I don't have access to a Vista machine, so I won't be able to test
symlink support.