> Chris, > > OK. I ran the strace test as you requested. > > Here's the invocation of strace I used in place of the unadorned "rm -fr > subdir" invocation from my earlier report: > > % strace -d -n -S 1 -w -o rm-fr-strace-out rm -fr subdir > > > I waited a few seconds then closed the sub-window. > > A Bzip2-compressed form of "rm-fr-strace-out" is attached (19.77 : 1 > compression!). A 170-column-wide window will eliminate line wrapping. > > If you seach for "lstat: entering" you'll see the infinitely repeating > sequence of operations. I'm not entirely sure, but that appears to be the > "entry point" of the loop. There appear to be 270 iterations present in the > strace log. > > If you're a Vim-er, this macro will help you see the pattern: > > :map ^[N Nzz > > ("^[" is an escape, naturally, which requires a prefix CTRL-V if entered > manually--mine originates in my .vimrc). > > Prime the search patter given above and then enter repeated ALT-N and > you'll see that only the timestamps along the left change. > > > One last piece of information, after running strace and killing the waiting > Java program, "subdir/target" is gone and a simple "rmdir subdir" succeeds. > > > Let me know if I can help further.
I've just looked over the sources to _unlink in Cygwin and the rm command. The problem as far as I can see is that if there is a sharing violation then the file being deleted is added to a queue of files to be deleted later. However if you list the contents of the directory the file was originally in, it will still show up. The second problem is this: 174347 [main] rm 2052 fhandler_disk_file::readdir: 0x0 = readdir (0xA012470) 174849 [main] rm 2052 fhandler_disk_file::readdir: 0xA012474 = readdir (0xA012470) (.) This shouldn't happen. The remove_cwd_entries function in rm's remove.c should return when readdir returns NULL. I can only presume this is a result of HAVE_WORKING_READDIR being undefined in fileutil's config.h. On the other hand, I've just configured fileutils now and HAVE_WORKING_READDIR is defined as 1. Maybe something changed in the Cygwin DLL between the last distribution of fileutils and now. The result of the second problem is that rm calls unlink to delete the file 'target', unlink suceeds, then rm starts reading the directory again. But because the file wasn't really removed, the first problem manifests itself: readdir returns an entry for 'target' again and then rm tries to delete it again, ad infinitum. Perhaps the maintainer of fileutils could contribute his or her opinion on this. Regards 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/