This is the mail archive of the
mailing list for the Cygwin project.
Re: rename oddity on 1.5
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 1 Oct 2009 18:31:50 +0200
- Subject: Re: rename oddity on 1.5
- References: <loom.20091001T180744email@example.com>
- Reply-to: cygwin at cygwin dot com
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple