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: Bruno Haible
Subject: Re: rename vs. hard links to the same file
Date: Tue, 5 Jun 2001 17:57:02 +0200 (CEST)

Jim Meyering writes:

> So the rename function in the GNU C library silently
> `succeeds' and doesn't have any effect.

You are right. Here is a simpler testcase.

$ cat > rename.c <<EOF
#include <stdio.h>
#include <unistd.h>

int main (int argc, char* argv[])
{
  return rename (argv[1], argv[2]) < 0;
}
EOF
$ gcc -O -Wall rename.c -o rename
$ rm -f a b
$ touch b
$ ln b a
$ ./rename a b
$ echo $?
0
$ ls -l a b 
-rw-r--r--   2 haible   users           0 Jun  5 17:42 a
-rw-r--r--   2 haible   users           0 Jun  5 17:42 b

I think it's a Linux kernel bug. (both 2.2.x and 2.4.4).

> That's what most people would expect, but not what POSIX appears
> to mandate.

The newest text I have (Austin SUSV3 draft 6) says the following about
the rename() function:

    The functionality described on this reference page is aligned with
    the ISO C standard. Any conflict between the requirements
    described here and the ISO C standard is unintentional. This
    volume of IEEE Std 1003.1-200x defers to the ISO C standard.

    The rename( ) function shall change the name of a file. The old
    argument points to the pathname of the file to be renamed. The
    new argument points to the new pathname of the file. If
    either the old or new argument names a symbolic link, rename( )
    shall operate on the symbolic link itself, and shall not resolve
    the last component of the argument. If the old argument and the 
    new argument resolve to the same existing file, rename( ) shall
    return successfully and perform no other action.

    If the old argument points to the pathname of a file that is not a
    directory, the new argument shall not point to the pathname of a
    directory. If the link named by the new argument exists, it shall
    be removed and old renamed to new. In this case, a link named
    new shall remain visible to other processes throughout the
    renaming operation and refer either to the file referred to by new
    or old before the operation began. Write access permission is
    required for both the directory containing old and the directory
    containing new.

So what does the second paragraph wording ("same existing file")
really mean: rename("a","a") or also rename("a","b") ? I think
"resolve" mean to only resolve symbolic links, and ignore hard link
relationships.

Bruno



reply via email to

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