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: rename oddity on 1.5

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

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