Re: "mv a b/" when b does not exist

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 11/29/2005 11:16 PM:
> 
> No, because POSIX requires that "Write access permission is required
> for the directory containing 'old' and the directory containing
> 'new'."  Here 'new' is "b/", which is equivalent to "b/.".  So the
> directory containing 'new' is "b".  But "b" does not exist, so
> 'rename' can't have write access to it.

I disagree.  Your quote came from the EACCES text, not the DESCRIPTION;
and I claim that if rename("a", "b/") is to fail because "b/" doesn't
exist, it should fail with ENOTDIR or ENOENT, not EACCES.  My argument is
that 'new' being "b/" is DIFFERENT than "b/.".  During pathname
resolution, the two are treated the same, but pathname resolution is only
used up to the point where it is determined that b/. does not name a
non-directory (since b does not yet exist).  From there, POSIX no longer
requires pathname resolution, so I maintain that Linux is still
POSIX-compliant by allowing rename("a", "b/") to succeed, but that
rename("a", "b/.") must fail since "b/." has a trailing dot component (and
because the parent of b/. does not exist).

We should probably bring this up on the austin mailing list.  This was
also discussed recently in light of my defect XSH ERN 108,
http://www.opengroup.org/austin/docs/austin_270.txt.

> 
> As far as changing 'mv' goes, I see two competing goals here:
> 
> A.  Have 'mv' conform to POSIX even if 'rename' does not.
> 
> B.  Have 'mv' do whatever 'rename' does, even if 'rename' does not
>     conform to POSIX.
> 
> We should pick either (A) or (B).  We can't do both at the same time.
> We shouldn't do (A) for non-directories and (B) for directories (which
> seems to be what's being proposed here).
> 
> I'd be happy to help with either (A) or (B).  Personally I have a mild
> preference for (B) since it's easier to implement (and it lets us
> blame the kernel guys if some POSIX pedant bugs us :-).

I also would favor (B).  But we certainly need testsuite additions to
ensure that we don't introduce future regressions against this decision.

- --
Life is short - so eat dessert first!

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

iD8DBQFDjbhN84KuGfSFAYARAgkxAJ9CEeKzwVGb0Oqv8BCySIxWaEu8PwCglDiX
xsyLzPt8bJXj0p8s1/QmZy0=
=WmAz
-----END PGP SIGNATURE-----