Re: BUG: Cygwin implementation of Debian package tools

[Reini Urban <rurban at x-ray dot at>]

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/