This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 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);
   perror(buf);
   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 
Austin:

https://www.opengroup.org/sophocles/show_archive.tpl?source=L&listname=austin-
group-l&first=1&pagesize=80&searchstring=rename&zone=G

https://www.opengroup.org/sophocles/show_mail.tpl?
CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=5156

http://lists.gnu.org/archive/html/bug-coreutils/2003-04/msg00042.html

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:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]