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: <5.2.0.9.2.20030123075017.01d8fe08@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Thu, 23 Jan 2003 07:54:50 -0800 To: cygwin AT cygwin DOT com From: Randall R Schulz Subject: RE: Bug in rm -r with locked files In-Reply-To: References: <20030121201944 DOT GE17833 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Chris J., At 02:47 2003-01-23, Chris January wrote: > > It's not a completely intractable problem. I think that someone (Chris > > January?) provided a workaround at one point. "cygserver" could also > > provide a possible solution someday. > >The best solution, IIRC, was to move the locked files elsewhere on the same >volume (which should be allowed) if they can't be unlinked, and then unlink >them later. So there would be a directory of files waiting to die if you >like :) Obviously you'd have to give them unique names, but you can just use >random numbers. Again, I think this misses the point. While Windows sees the file as open (or a directory that is current for some process), it cannot be renamed, relocated or deleted, can it? I know very little about the Windows APIs, but the behavior I see from Windows strongly suggests this is the case. Is there some kind of override to these common "interlocks" that Windows imposes? Are they only strictly enforced in Windows Explorer? Randall Schulz >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/