On Oct 1 16:25, Eric Blake wrote: > 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.
Did you try to look what happens in sysinternal's procmon? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
