rename oddity on 1.5

[Eric Blake <ebb9 at byu dot net>]

I'm debating about doing one final coreutils drop for cygwin 1.5, since 
coreutils 6.10 is comparatively old compared to the upcoming 7.7.  In the 
process, I'm trying to write a wrapper for coreutils to work around various 
rename(2) bugs (my patch for coreutils already deals with bugs in Solaris 9 and 
10, and NetBSD 1.6).  For the good news, the testsuite for coreutils passes all 
rename(2) tests on a self-built cygwin 1.7 without needing any wrapper (self-
built, because cgf has not yet checked in his patch to fix a/.// detection).

But I'm running into a weird case on cygwin 1.5.  I've got two machines, both 
running Windows XP, but the same sequence of commands on the two machines gives 
different behavior.  Can anyone explain this, other than a possibility of BLODA?

$ mkdir a b
$ touch a/f
$ mv -T a b
$ rm b/f
$ rmdir b
$ ls

On one machine, this works as expected, but on the other, the rmdir action 
brings directory 'a' back into existence.  The problem looks like it only 
occurs when moving a non-empty directory to overwrite an empty one.

I can work around it - in the wrapper, call rmdir(dst) if destination exists 
and is a directory, prior to calling rename(src,dst).  But I'd like an 
explanation of why I need to do it, if anyone knows, since it means the rename 
operation is no longer atomic.

-- 
Eric Blake



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple