Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: <232810-220031221163510989@M2W098.mail2web.com> X-Priority: 3 Reply-To: lhall AT rfk DOT com X-Originating-IP: 209.113.174.244 From: "lhall AT pop DOT ma DOT ultranet DOT com" To: gael DOT mulat AT polyspace DOT com, cygwin AT cygwin DOT com Subject: Re: Bug in rm -r with locked files Date: Tue, 21 Jan 2003 11:35:10 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 21 Jan 2003 16:35:11.0014 (UTC) FILETIME=[10F7EC60:01C2C16B] Note-from-DJ: This may be spam Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h0LGrY429499 You may find the 'handle' utility from www.sysinternal.com a handy (no pun intended :-) ) tool for determining which files are opened by which processes. This might help you track down what's locking files on you. In terms of the 'vim' issue, it piqued my interest enough that I did some investigation. Running Cygwin 1.3.17-1, 1.3.18-1, and today's snapshot all reproduced the hang for me. So I took a simple step and ran strace on the 'rm' process. It showed an error code of 5 (Access is denied.) for 'C:\tmp\foo\.bar.swp'. Conclusion: the problem I see here has to do with 'vim' locking the recovery file. Adding '-n' to the flags for 'vim' removed the hang. Corinna, any chance you have your recovery file directories set to something that doesn't include '.'? If that explains the difference in behavior we're seeing, then I think we'll have solved one mystery and at least have a workaround to the problem. Larry Original Message: ----------------- From: Gael Mulat Gael DOT Mulat AT polyspace DOT com Date: Tue, 21 Jan 2003 15:49:02 +0100 To: cygwin AT cygwin DOT com Subject: Re: Bug in rm -r with locked files Corinna Vinschen wrote: > On Tue, Jan 21, 2003 at 12:50:18PM +0100, Gael Mulat wrote: > > Hi, > > > > This is a bug report about rm (package fileutils, version 4.1-1) on W2K. > > > > Test case: take 2 cygwin shells. > > shell 1: > > mkdir /tmp/directory > > vi /tmp/directory/file > > > > shell 2: > > /bin/rm -rf /tmp/directory > > > > The shell2 doesn't manage to remove the directory and goes into an > > infinite loop, taking 100% of the CPU. > > All is then OK if we go out of vi in the shell1. > > Which version of Cygwin and Vim are you using? I'm getting this: > > shell 1: > mkdir /tmp/foo > vi /tmp/foo/bar > :w <= To create file `bar' > Cygwin 1.3.17 VIM 6.1-2 Windows 2000 SP2 / SP3 Just to be precise if I was not clear: do not exit of vi ! In fact, I have noticed that the problem happens with vi, but it happens also with some other processes. I just don't know which ones. I found several times my Windows 2000 with the CPU at 100%, all the CPU was taken by a rm in my scripts on cygwin. I didn't found the process that held the lock, but I noticed that vi did the same... Gael. > shell 2: > rm -rf /tmp/foo <= returns immediately, having foo removed. > > Vim doesn't lock the file, so I wonder what you are discribing here. > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Developer mailto:cygwin AT cygwin DOT com > Red Hat, Inc. -- 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/ -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . -- 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/