Re: Bug in builtin function abspath

[Alessandro Vesely]

Eli Zaretskii wrote:
> > Date: Wed, 07 Jun 2006 07:57:11 -0400
> > From: Earnie Boyd <address@hidden>
> > Cc: Alessandro Vesely <address@hidden>, address@hidden
> >
> > > > 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?
> > ``mountvol /?'' on any XP box.
>
> Ah, okay.  But what does this have to do with symlinks?  These mount
> points don't behave like symlinks, no more so than SUBST'ed drive
> does.

There are two kinds of them: the other one is done with linkd, from the
resource kit (rktools, 11.8Mb, http://go.microsoft.com/fwlink/?LinkId=4544 )
Both kinds are detected by FILE_ATTRIBUTE_REPARSE_POINT, and can be read
with the API DeviceIoControl(), but then the former does not have a 'print'
part and the volume is given by a drive id, not the changeable "d:\". See
also http://www.codeproject.com/w2k/junctionpoints.asp

I guess symlinks in Vista won't be much different than that, but they
will be documented and supported. (Currently, the XP Search utility finds
some dozens of include files on a backward link, e.g. include/w32api->..,
where GNU find --although presumably linked with a dummy lstat()-- finds
exactly the single name given.)

When a symlink points to a subdirectory, it should make sense to use
"symlink/../not-in-cwd". In theory, NTFS provides for a reference to the
parent directory from each file record. However, I know no API to actually
get that value. Paths like "symlink/../not-in-cwd" yield file-not-found
using any of cmd's DIR, FindFirstFile(), or CreateFile().

Perhaps, Vista will amend that, and, since MS' stated purpose is to ease
porting, its new msvcrt will sport properly working lstat() and realpath().
In that case things will ``just work'' on their own.