Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-Id: <5.2.0.9.2.20030123075017.01d8fe08@pop3.cris.com>
Date: Thu, 23 Jan 2003 07:54:50 -0800
To: cygwin@cygwin.com
From: Randall R Schulz <rrschulz@cris.com>
Subject: RE: Bug in rm -r with locked files
In-Reply-To: <LPEHIHGCJOAIPFLADJAHCENDDDAA.chris@atomice.net>
References: <20030121201944.GE17833@redhat.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/