bug-glibc
[Top][All Lists]
Advanced

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

rename vs. hard links to the same file [Re: mv bug


From: Jim Meyering
Subject: rename vs. hard links to the same file [Re: mv bug
Date: 05 Jun 2001 16:06:49 +0200
User-agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.104

Bruno Haible <address@hidden> wrote:
| Hi,
|
| GNU mv, when asked to move a file onto one of its hardlinked aliases,
| does nothing.
|
| # mv --version
| mv (GNU fileutils) 4.1
| Written by Mike Parker, David MacKenzie, and Jim Meyering.
|
| Copyright (C) 2001 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.  There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
| # ls -l -i gcc i686-pc-linux-gnu-gcc
|  483620 -rwxr-xr-x    2 bin      bin        215969 May 12 15:03 gcc
|  483620 -rwxr-xr-x    2 bin      bin        215969 May 12 15:03 
i686-pc-linux-gnu-gcc
| # mv gcc i686-pc-linux-gnu-gcc
| # echo $?
| 0
| # ls -l -i gcc i686-pc-linux-gnu-gcc
|  483620 -rwxr-xr-x    2 bin      bin        215969 May 12 15:03 gcc
|  483620 -rwxr-xr-x    2 bin      bin        215969 May 12 15:03 
i686-pc-linux-gnu-gcc
|
| Still there! "gcc" should be gone!

Hi Bruno,

Thanks for the report.

That's what most people would expect, but not what POSIX appears
to mandate.  So the rename function in the GNU C library silently
`succeeds' and doesn't have any effect.  Here's a quote from the
glibc manual:

     One special case for `rename' is when OLDNAME and NEWNAME are two
     names for the same file.  The consistent way to handle this case
     is to delete OLDNAME.  However, in this case POSIX requires that
     `rename' do nothing and report success--which is inconsistent.  We
     don't know what your operating system will do.

And POSIX seems clear on this, at least in so far as it defers to
the rename function:

    ...

    The mv utility shall perform actions equivalent to the rename()
    function defined in the System Interfaces volume of IEEE Std
    1003.1-200x, called with the following arguments:

        a. The source_file operand is used as the old argument.
        b. The destination path is used as the new argument.

     If this succeeds, mv shall do nothing more with the current
     source_file and go on to any remaining source_files. If this fails
     for any reasons other than those described for the errno [EXDEV]
     in the System Interfaces volume of IEEE Std 1003.1-200x, mv shall
     write a diagnostic message to standard error, do nothing more with
     the current source_file, and go on to any remaining source_files.

Based on the note in the glibc manual, I presume others have carefully
considered whether GNU software should toe the POSIX line in this case,
in spite of the inconsistency.

Maybe they'll even share their thoughts with us? :-)

Jim



reply via email to

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