Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <4182B53D.1030501@familiehaase.de>
Date: Fri, 29 Oct 2004 23:25:17 +0200
From: "Gerrit P. Haase" <gp@familiehaase.de>
Organization: Esse keine toten Tiere
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Superbiskit@cox.net
CC: Cygwin General Discussion <cygwin@cygwin.com>
Subject: Re: BUG: Cygwin implementation of Debian package tools
References: <418278CB.6080204@cox.net>
In-Reply-To: <418278CB.6080204@cox.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Note-from-DJ: This may be spam

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.


Gerrit
-- 
=^..^=

--
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/