This is the mail archive of the
mailing list for the Cygwin project.
Re: New rename(2) function
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Wed, 1 Aug 2007 16:02:16 +0000 (UTC)
- Subject: Re: New rename(2) function
> 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
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
int main(int argc, char** argv)
if (argc < 3)
puts("Usage: rename <old> <new>");
int res = rename(argv, argv);
snprintf(buf, sizeof(buf), "result %d, errno %d", res, errno);
$ 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html