Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Aug 2001 13:46:30 -0400 (EDT)
From:      Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        <current@FreeBSD.ORG>, freebsd-standards@bostonradio.org
Subject:   Re: symlink(2) [Was: Re: tcsh.cat] 
Message-ID:  <200108311746.f7VHkU279910@khavrinen.lcs.mit.edu>
In-Reply-To: <20010901031439.A4397-100000@besplex.bde.org>
References:  <200108311443.f7VEh8h14038@green.bikeshed.org> <20010901031439.A4397-100000@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
[Attribution deleted for clarity; see referenced messages in the archives.]

>> >     $ ln -s '' foo
>> >     $ cp foo bar
>> >     cp: foo is a directory (not copied)

>> No, "foo" certainly _is_ a directory.  It is precisely the same thing as
>> ".".

> No, the empty pathname has been invalid and not an alias for "." since at
> least the first version of POSIX.

"foo" is not the empty pathname.  It is also not a directory; it is a
symbolic link.  The pathname resolution rules require that references
to "foo" be indistinguishable from references to "." (outside of
those functions which are defined not to follow symbolic links).

XBDd7 says:

# If a symbolic link is encountered during pathname resolution, the
# behavior shall depend on whether the pathname component is at the
# end of the pathname and on the function being performed. If all of
# the following are true, then pathname resolution is complete:

[...]

# 3. The function is required to act on the symbolic link itself, or
#    certain arguments direct that the function act on the symbolic
#    link itself.

Since this is not true (see below), pathname resolution continues:

# In all other cases, the system shall prefix the remaining pathname,
# if any, with the contents of the symbolic link. If the combined
# length exceeds {PATH_MAX}, and the implementation considers this to
# be an error, errno shall be set to [ENAMETOOLONG] and an error
# indication shall be returned. Otherwise, the resolved pathname shall
# be the resolution of the pathname just created.  If the resulting
# pathname does not begin with a slash, the predecessor of the first
# filename of the pathname is taken to be the directory containing the
# symbolic link.

The result of this construction rule is clearly an empty pathname.
The definition of ``pathname'' does not prohibit empty pathnames:

# [A pathname] has an optional beginning slash, followed by zero or
# more filenames separated by slashes. A pathname may optionally
# contain one or more trailing slashes. Multiple successive slashes
# are considered to be the same as one slash.

We seem to be in a region of undefined behavior here.

XCUd7 says (in defining `cp'):

# If source_file is a file of type symbolic link:

# * If neither the -R nor -r options were specified, cp shall take
#   actions based on the type and contents of the file referenced by
#   the symbolic link, and not by the symbolic link itself.

[...]

# For each source_file, the following steps shall be taken:

# 2. If source_file is of type directory, the following steps shall be
#    taken:

# a. If neither the -R or -r options were specified, cp shall write a
#    diagnostic message to standard error, do nothing more with
#    source_file, and go on to any remaining files.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108311746.f7VHkU279910>