[Top][All Lists]

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

Re: rename("symlink-to-dir/", "name") behavior

From: Eric Blake
Subject: Re: rename("symlink-to-dir/", "name") behavior
Date: Fri, 22 Feb 2008 05:35:26 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

Hash: SHA1

According to Eric Blake on 1/28/2008 6:28 AM:
| According to Geoff Clare on 1/28/2008 2:57 AM:
| |>
| |> My strict reading of the current wording in draft 4 does not permit
| Linux'
| |> behavior (even though it is more useful, in my opinion), since the
| |> trailing slash on B/ means that the old argument names a directory by
| the
| |> rewritten path resolution rules in XBD 4.12 (line 3008).
| |
| | Right.  The behaviour on Solaris and FreeBSD is the one required
| | by the standard.  It is also the behaviour on all certified UNIX03 and
| | POSIX01 systems because a test for it is included in the tests for
| | rename() in The Open Group's UNIX03/POSIX01 test suite.
| |
| | (I just checked, and Linux does indeed fail the test, which reports an
| | unexpected ENOTDIR error.)
| |
| | Linux also gives ENOTDIR for rmdir("B/"), instead of removing A and
| | leaving B as a broken link as the standard requires.
| However, I find the Linux behavior (for rename at least) much friendlier,
| and would like to see the standard permit that behavior.  So it sounds
| like when I write the aardvark, that both behaviors need to be permitted,
| rather than declaring existing behavior of UNIX03/POSIX01 invalid.

I wrote the aardvark along those lines, and it was rejected in yesterday's
meeting of the Austin Group.  They argued that Linux is allowed to fail to
follow symlink-to-dir/ in the rename and rmdir case, but only if it
returns a different errno than ENOTDIR.


I wonder if we would have much luck proposing a patch to the Linux kernel
folks to do just that?  Otherwise, I'm afraid that coreutils mv and rmdir
will just have to remain non-POSIX-compliant on Linux because the
underlying syscall is violating semantics.

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

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (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]