Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote:
> 
> > On Fri, 15 Jun 2001 06:31:12 -0700 (PDT)
> > David Wolfskill <[EMAIL PROTECTED]> wrote:
> > 
> > DW> Indeed: it is my understanding that the "path name" interpretation is
> > DW> an issue at the time of reference, not (necessarily) the time of
> > DW> creation.  It has, to the best of my knowledge, been valid to create a
> > DW> symlink prior to a point when its target exists.
> > 
> >     It has been on evey platform I have ever used ln -s on.
> > 
> > DW> One may well argue that this is "broken" in some way(s).  Still, changing
> > DW> it at this point could well be considered  a POLA violation, at best.
> > 
> >     I would argue loud and long that changing that *would* be broken. There
> > is never a guarantee (or even an implication) that a symlink points to a
> > valid directory entry (think unmounted filesystems, NFS ...). I find it hard
> > to imagine why creation time should be special in that regard.
> 
> We are (or at least I am) talking about changing it to prevent links to a
> string that can _never_ be a valid pathname.  Fortunately, in POSIX there
> is only one such string (the empty string).
> 
> Here's an example of a standard utility being clueless about symlinks to
> nothing:
> 
>     $ ln -s '' foo
>     $ cp foo bar
>     cp: foo is a directory (not copied)
> 
> foo is certainly not a directory.  The bug seems to be in fts.

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

> cp is also broken for symlinks to valid pathnames for nonexistent files;
> 
>     $ rm -f foo
>     $ ln -s /nonesuch foo
>     $ cp foo bar
> 
> This duplicates foo as a symlink, but should just fail.
> 
> Bruce

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]                    `------------------------------'



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to