This is the mail archive of the
mailing list for the Cygwin project.
rename oddity on 1.5
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 1 Oct 2009 16:25:52 +0000 (UTC)
- Subject: rename oddity on 1.5
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
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple