bug-coreutils
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: "mv a b/" when b does not exist
Date: Thu, 01 Dec 2005 06:08:08 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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

According to Paul Eggert on 11/30/2005 10:57 AM:
> 
> It does appear that POSIX does not specify what should happen when you
> do this:
> 
> mkdir new
> cd new
> touch a
> mv a b/c
> 
> That is, if "b" does not exist, then rename("a", "b/c") is not
> required to fail.  That's very strange, but there's nothing in the
> existing language that requires it to fail.

I read "ENOTDIR: A component of either path prefix is not a directory" as
forbidding rename("a", "b/c") when b does not exist.  But yes, the wording
earlier in the DESCRIPTION is weak, with the restriction only being that
"Write access permission is required for the directory containing old and
the directory containing new," such that without the additional text under
ENOTDIR you could argue that it is "." that contains "b/c" rather than
"./b" containing "c", since 'new' was "b/c".

> 
> Hence you are right: rename("a", "b/") is not required to fail either.
> 
> I view this as a defect in POSIX.
> 
> 
>>rename("a", "b/.") must fail since "b/." has a trailing dot component
> 
> 
> I see no difference here.  POSIX allows rename("a", "b/.") to succeed,
> using the same logic as above.

No.  The resolution of XSH 108 explicitly requires failure if a trailing
component is . or .., along with words in EINVAL to that effect.
Therefore, I contend that rename("a", "b/.") MUST fail, but that
rename("a", "b/") MAY fail or succeed, given the current wording as
corrected by the defect report.

This is similar to the issue that we discussed a couple months ago as to
whether mkdir("b/", 0777) is allowed to succeed (even though mkdir("b/.",
0777) must fail), and whether rmdir("b/") is allowed to succeed (even
though rmdir("b/.") must fail.

My argument remains that pathname resolution must treat b/ as b/. when
determining that the filename exists and is a directory (or does not
exist), but that when the trailing dot is not explicitly present, pathname
resolution is only done to check the preconditions of the syscall, as
opposed to the entire call treating a trailing slash the same as an
implicit trailing dot.

- --
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

iD8DBQFDjvW484KuGfSFAYARAhATAKDSGoAi3419R/ugPoZhRdyIMdU/UgCfaUSo
CAtxMJYV4xDM2X4M0x5bTBY=
=kt0W
-----END PGP SIGNATURE-----




reply via email to

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