This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in rm -r with locked files


lhall@pop.ma.ultranet.com wrote:
You may find the 'handle' utility from www.sysinternal.com a handy
(no pun intended :-) ) tool for determining which files are opened
by which processes.
I don't think that was the primary issue. The issue was that if a process is using a directory as its working directory (chdir()'ed into it), "rm -rf" goes into an infinite loop attempting to remove the directory (rather than print an error and move on).

Definitely a bug, and still a bug.

NOTE: The "-f" flag is crucial to reproducing this - without the "-f", rm gives an error and exits.

Here's how to reproduce

From one bash:

mkdir /cygdrive/c/temp/foo (some path)
vi /cygdrive/c/temp/foo/x.txt
:w

From a second bash:

rm -rf /cygdrive/c/temp/foo
(Hangs, with rm.exe taking ~100% of the CPU)

My package versions:
fileutils 4.1-1
cygwin 1.3.18-1
bash 2.05b-8
vim 6.1-2

This doesn't happen, by the way, if you simply "cd" into the directory in the first bash, and do nothing else - in that situation, the "rm -rf" just emits a "Permission denied" error and exits. Does bash do something special to the directories it chdir()s to?



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]