[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: readlink(1) behavior

From: Eric Blake
Subject: Re: readlink(1) behavior
Date: Fri, 18 Sep 2009 05:35:04 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

Hash: SHA1

According to Jim Meyering on 9/18/2009 4:47 AM:
> Assuming ln -s /nowhere dangling-symlink,
> New behavior:
>     $ ./readlink -fv dangling-symlink/
>     /nowhere
> Previous:
>     $ readlink -fv dangling-symlink/
>     readlink: dangling-symlink/: No such file or directory
>     [Exit 1]

On one hand:

ln -s dangling link => 0
stat dangling/ => ENOENT
stat link/ => ENOENT
mkdir link/ => 0

the behavior is consistent - a single mkdir can create the lone missing
element in the (expanded) pathname.  If we really claim that -f implies
that a missing last element is acceptable if it can be created by the same
name, then that explains the new behavior.

On the other hand, continuing the above example, there are some Linux
interfaces which distinguish between a dangling symlink with trailing
slash compared to a missing file with trailing slash:

rmdir link/ => ENOTDIR
rmdir dangling/
rmdir dangling/ => ENOENT
rmdir link/ => ENOTDIR

This difference does not exist on Solaris (which follows the
counter-intuitive POSIX rule that the first 'rmdir link/' remove dangling
rather than fail with ENOTDIR).

So, we need to decide whether I should work on changing the
CAN_ALL_BUT_LAST mode to explicitly differentiate between a missing
element with a trailing slash (ok) compared to an existing but dangling
symlink with a trailing slash (fail, as before this change); or whether
the behavior on a dangling symlink with a trailing slash is an intentional
change for consistency.

Once we make that decision, we either need to patch coreutils' NEWS or I
need to fix the regression in gnulib canonicalize.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]