bug-glibc
[Top][All Lists]
Advanced

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

Re: rename vs. hard links to the same file


From: Paul Eggert
Subject: Re: rename vs. hard links to the same file
Date: Tue, 5 Jun 2001 18:43:13 -0700 (PDT)

> From: Bruno Haible <address@hidden>
> Date: Tue, 5 Jun 2001 17:57:02 +0200 (CEST)
> 
> Austin SUSV3 draft 6 says the following about the rename() function:
> 
>     If the old argument and the new argument resolve to the same
>     existing file, rename( ) shall return successfully and perform
>     no other action.
> 
> So what does the second paragraph wording ("same existing file")
> really mean:

It is referring to Pathname Resolution (XBDd6 section 4.11); this
resolves a pathname to a particular file in a file hierarchy.

> I think
> "resolve" mean to only resolve symbolic links, and ignore hard link
> relationships.

Since "rename" does not dereference symbolic links, pathname
resolution in this case resolves only any symbolic links that are
followed by "/" in the pathname; it does not resolve any symbolic link
at the end of the pathname.

You're right that resolution ignores hard link relationships.
However, the standard seems pretty clear that if "a" and "b" are hard
links, then they resolve to the same file and therefore
rename("a","b") must succeed and do nothing.  If it matters, the
Solaris 8 kernel also conforms to the standard here.  (Admittedly the
standard is a botch.)

While we're on the subject, it seems to me that GNU fileutils 4.1 `mv'
still does not conform to the standard.  For example, d6 says that the
following mv commands must all silently do nothing and succeed, and
yet only the first command works as the spec requires:

        $ touch a; ln a b
        $ mv a b
        $ mv a a
        mv: `a' and `a' are the same file
        $ mv a .
        mv: `a' and `./a' are the same file
        $ mv . .
        mv: `.' and `./.' are the same file
        $ mv .. .
        mv: `..' and `./..' are the same file
        $ mv ../. ..
        mv: `../.' and `../.' are the same file
        $ mv ../.. ..
        mv: `../..' and `../..' are the same file
        $ mv /. /
        mv: `/.' and `/.' are the same file
        $ mv /. /.
        mv: `/.' and `/./.' are the same file
        $ mv /. /..
        mv: `/.' and `/../.' are the same file
        $ mv /.. /
        mv: `/..' and `/..' are the same file
        $ mv /.. /.
        mv: `/..' and `/./..' are the same file
        $ mv /.. /..
        mv: `/..' and `/../..' are the same file

(Dizzy yet?  I am.  :-)

Also, here are some other test cases where, as far as I can see the
behavior is undefined -- due to a bug in the standard!  In these cases
the standard talks about the "last pathname component" of the source,
but here the source has no pathname components:

        $ mv / /
        mv: `/' and `/' are the same file
        $ mv / /.
        mv: cannot overwrite directory `/./'
        $ mv / /..
        mv: cannot overwrite directory `/../'

If it's any consolation, Solaris 8 /usr/xpg4/bin/mv agrees with GNU mv
(though the wordings of the error messages differ) -- except for the
case of "mv a b" that prompted this thread.  In that case, Solaris mv
issues the diagnostic that "a and b are identical".



reply via email to

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