New rename(2) function

Eric Blake
Wed Aug 1 16:32:00 GMT 2007

> Corinna wrote:

[Bah - gmane can't post to cygwin-devel, so I'm cross-posting (in order to 
reply now, rather than waiting till when I'm home).]

> > Also, where do you check that rename("a","a") is a successful no-op, as
> > well as rename("a","b") when a and b are hard links to the same inode
> > (perhaps both of these cases are covered by NtSetInformationFile?)
> rename ("a", "a") is a no-op because NtSetInformationFile will just
> return with status 0, doing nothing.
> I don't see anything about rename("a","b") with both hardlinks to the
> same inode being a no-op.  Neither in Linux, nor in SUSv3, nor in IEEE
> P1003.1 Draft 3.  Actually, rename("a","b") will rename a to b, thus
> decreasing the link count of the file by 1, on Linux as well as on
> Cygwin.

Huh?  SUSv3 states this:

"If the old argument and the new argument resolve to the same existing file, 
rename() shall return successfully and perform no other action."

Note that the requirement is careful to mention resolving to the same file (and 
not merely the same string for the two names, or even the same directory entry 
possibly via different symlink paths).

And on Linux, I get this:

$ cat rename.c
#include <stdio.h>
#include <errno.h>

int main(int argc, char** argv)
   if (argc < 3)
      puts("Usage: rename <old> <new>");
      return 1;
   int res = rename(argv[1], argv[2]);
   snprintf(buf, sizeof(buf), "result %d, errno %d", res, errno);
   return 0;
$ touch l1
$ ln l1 l2
$ ./rename l1 l2
result 0, errno 0: Success
$ ls -l l?
-rw-r--r--  2 ericb cygwin 0 Aug  1 14:48 l1
-rw-r--r--  2 ericb cygwin 0 Aug  1 14:48 l2

ie. a pure rename was a nop, rather than unlinking l1.  Note, however, that mv
(1) from coreutils will indeed unlink l1 and reduce the link count of l2.  
Indeed, there are a number of posts related to this issue in both coreutils and 

And XSH ERN 88 (which proposed rewording POSIX with s/same existing file/same 
existing directory entry) was rejected.

It looks like draft 3 of POSIX 200x hasn't touched this area yet, so I'll raise 
the issue again on the austin lists on the mv(1) side of things.  But it looks 
like cygwin's rename(2) will need to take this POSIX rule into account, to 
match linux.

Eric Blake

Unsubscribe info:
Problem reports:

More information about the Cygwin-developers mailing list