Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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:	<4183C2EC.1090006@x-ray.at>
Date:	Sat, 30 Oct 2004 18:35:56 +0200
From:	Reini Urban <rurban AT x-ray DOT at>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817
MIME-Version:	1.0
To:	Cygwin General Discussion <cygwin AT cygwin DOT com>
Subject:	Re: BUG: Cygwin implementation of Debian package tools
References:	<418278CB DOT 6080204 AT cox DOT net> <4182B53D DOT 1030501 AT familiehaase DOT de> <41830281 DOT 6080605 AT cox DOT net>
In-Reply-To:	<41830281.6080605@cox.net>
X-IsSubscribed:	yes

David A. Cobb schrieb:
> Gerrit P. Haase wrote:
>> David A. Cobb wrote:
>>> ++rm.exe    <==== getting 98% of the CPU time and not making any
>>> progress.  Watching the handles display, I see an open handle on what
>>> must be the first *.deb file found so I'm pretty sure of the "no
>>> progress -= stuck!" diagnosis.
>>
>> If there is a Windows process which has a handle on a file or directory
>> open, rm shows this behaviour occasionally.  e.g. try to run
>> rm -rf /path/to/directory
>> while having an explorer view open on this directory (or a 
>> subdirectory of directory).
>>
>> It happens i.e. often for me when using the generic-build-script, if 
>> invoking with install or reconf which does rm -rf .build / .inst and
>> having an explorer shell open in one of the (sub)directories to be
>> removed from the script -> it seems to hang and it is always rm.
>>
>> Maybe Reini can look into this issue, it seems he is already working
>> at the coreutils sources.  But I think it is a Windows feature and 
>> this is probably difficult to work around.

strace rm -r <some stale dir>

about thousands of:
  41 3557965 [main] rm 1360 __cygwin_lock_unlock: threadcount 1.  not 
unlocking
  41 3558006 [main] rm 1360 __cygwin_lock_unlock: threadcount 1.  not 
unlocking
  40 3558046 [main] rm 1360 __cygwin_lock_unlock: threadcount 1.  not 
unlocking
  40 3558086 [main] rm 1360 __cygwin_lock_lock: threadcount 1.  not locking
  40 3558126 [main] rm 1360 __cygwin_lock_lock: threadcount 1.  not locking
  40 3558166 [main] rm 1360 __cygwin_lock_lock: threadcount 1.  not locking
  40 3558206 [main] rm 1360 __cygwin_lock_lock: threadcount 1.  not locking
  40 3558246 [main] rm 1360 __cygwin_lock_unlock: threadcount 1.  not 
unlocking

$ strace rm -r findutils-4.1.7-4 > rm.strace
rm: Entfernen von Verzeichnis "findutils-4.1.7-4/find" nicht m"oglich: 
Device or resource busy

$ grep -c  __cygwin_lock_ rm.strace
4012

$ find findutils-4.1.7-4
findutils-4.1.7-4
findutils-4.1.7-4/find

# so it's empty with on open handle to the "find" dir
# but this is effectively a non-issue:

$ time rm -r findutils-4.1.7-4
rm: Entfernen von Verzeichnis "findutils-4.1.7-4/find" nicht m"oglich: 
Device or resource busy

real    0m0.099s
user    0m0.030s
sys     0m0.031s

# high cpu for a short amount of time is not really annoying.

$ rm --version
rm (coreutils) 5.2.1

unlink() is using pierre's latest patch (GREAT patch, thanks btw), but 
all this can also be observed with the current versions.

> It's always good to know I'm not the only one getting things like this.  
> At least if I've lost my mind I have companions.
> 
> It's hard to see how a Windows misfeature prevents rm.exe from deleting 
> a file and exiting.  But, yeah, the --recurse could create  some sort of 
> situation I guess.  But I don't see a bunch of handles on nodes in a 
> directory branch -- just the one .deb file.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -