Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <006301c1ddbe$da7b6850$0100a8c0@advent02>
From: "Chris January" <chris AT atomice DOT net>
To: <cygwin AT cygwin DOT com>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020406094553 DOT 02433da0 AT pop3 DOT cris DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020406113800 DOT 023e2c98 AT pop3 DOT cris DOT com>
Subject: Re: Infinite Loop In "rm -fr" When Busy File Encountered
Date: Sun, 7 Apr 2002 00:00:30 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

> Chris,
>
> OK. I ran the strace test as you requested.
>
> Here's the invocation of strace I used in place of the unadorned "rm -fr
> subdir" invocation from my earlier report:
>
> % strace -d -n -S 1 -w -o rm-fr-strace-out rm -fr subdir
>
>
> I waited a few seconds then closed the sub-window.
>
> A Bzip2-compressed form of "rm-fr-strace-out" is attached (19.77 : 1
> compression!). A 170-column-wide window will eliminate line wrapping.
>
> If you seach for "lstat: entering" you'll see the infinitely repeating
> sequence of operations. I'm not entirely sure, but that appears to be the
> "entry point" of the loop. There appear to be 270 iterations present in
the
> strace log.
>
> If you're a Vim-er, this macro will help you see the pattern:
>
> :map ^[N Nzz
>
> ("^[" is an escape, naturally, which requires a prefix CTRL-V if entered
> manually--mine originates in my .vimrc).
>
> Prime the search patter given above and then enter repeated ALT-N and
> you'll see that only the timestamps along the left change.
>
>
> One last piece of information, after running strace and killing the
waiting
> Java program, "subdir/target" is gone and a simple "rmdir subdir"
succeeds.
>
>
> Let me know if I can help further.

I've just looked over the sources to _unlink in Cygwin and the rm command.
The problem as far as I can see is that if there is a sharing violation then
the file being deleted is added to a queue of files to be deleted later.
However if you list the contents of the directory the file was originally
in, it will still show up.
The second problem is this:
 174347 [main] rm 2052 fhandler_disk_file::readdir: 0x0 = readdir
(0xA012470)
 174849 [main] rm 2052 fhandler_disk_file::readdir: 0xA012474 = readdir
(0xA012470) (.)
This shouldn't happen. The remove_cwd_entries function in rm's remove.c
should return when readdir returns NULL. I can only presume this is a result
of HAVE_WORKING_READDIR being undefined in fileutil's config.h. On the other
hand, I've just configured fileutils now and HAVE_WORKING_READDIR is defined
as 1. Maybe something changed in the Cygwin DLL between the last
distribution of fileutils and now.
The result of the second problem is that rm calls unlink to delete the file
'target', unlink suceeds, then rm starts reading the directory again. But
because the file wasn't really removed, the first problem manifests itself:
readdir returns an entry for 'target' again and then rm tries to delete it
again, ad infinitum.
Perhaps the maintainer of fileutils could contribute his or her opinion on
this.

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/