Re: 1.7.7: rm -rf sometimes fails - race condition?

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Fri, Dec 10, 2010 at 06:49:09PM +0100, Matthias Andree wrote:
>Greetings,
>
>I see that "rm -rf" on a directory sometimes fails, like here:
>
>|>>> Creating source package
>| fetchmail-6.3.19-1.cygport
>| fetchmail-6.3.19-1.cygwin.patch
>| fetchmail-6.3.19.tar.bz2
>|>>> Removing work directory in 5 seconds...
>|>>> Removing work directory NOW.
>| rm: cannot remove `/usr/src/fetchmail-6.3.19-1/inst/usr/share/locale/da':
>Directory not empty
>| Command exited with non-zero status 1
>
>Alternatively, you get "...in use" for an error, however, in this case, it
>appears that the corresponding syscall triggered by rm(1) had already returned
>but the file wasn't fully removed from the directory yet.
>
>I've seen this happen for a while now.  This happens sporadically, and retrying
>the operation usually succeeds, so it matters less in an interactive shell.
>However, this often breaks scripts, in this case, cygport.
>
>This looks like either a premature return from a syscall or libcall, or like a
>genuine race in the system.
>
>In case it matters, this is
>- Windows 7 Prof. 32-bit German
>- with Sophos Endpoint Security and Control ver. 9 and
>- Microsoft Windows Defender.
>- coreutils 8.5-2
>- uname -a:
>  CYGWIN_NT-6.1 somehost 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
>
>
>Has anyone seen similar things?

Yes and you seem to have nailed the problem - it happens when a virus checker
hooks into a syscall and allows it to return before completion.  I don't think
we want to modify Cygwin to not trust success return values from system calls.

cgf

--
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