> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
> The bug that stat(2) on a null symlink classifies the target of the symlink
> as a directory is caused by resolving the pathname to "" and then not
> returning ENOENT in namei(). "" tends to be interpreted as "." unless
> it is specially disallowed, and that's what happens here. "" is only
> disallowed for the unresolved pathname. Since the bug is in namei(), it
> affects all syscalls that deal with pathnames. E.g., you can open()
> null symlinks; this is equivalent to opening ".".
Err... not quite. Given a path like
<prefix>/<symlink><suffix>
after the substitution of <symlink> with its target, the
search must start at the root if <symlink> target starts with
a "/". So it seems to me the _use_ of a "" target symlink
(in all but the final path component position) is exactly
equivalent to the use of a "/" target symlink. When used in
the final path component position, you get either the symlink
or ENOENT. The POSIX excerpt Garrett quoted seems to match
this.
This is surprising at first but hardly worth adding a
singularity (an exception). So IMHO for a "" target symlink
used in _any place other than the final component_ it should
be treated as if it points to just "/". Matt Dillon's patch
seems to return ENOENT regardless of how a "" target symlink
is used.
This is not a big deal but I care about not having
unnecessary exceptions.
[Yes, I have read through this thread]
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
