http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #3 from Dan Kegel dank@kegel.com 2009-01-29 23:29:56 --- In http://blogs.msdn.com/oldnewthing/archive/2005/02/03/366277.aspx Raymond Chen says -- snip -- The FAT file system was simple enough that the necessary search state fit in the reserved bytes ... However, ... non-FAT file systems may have additional state to track that ... can't be stored in the reserved space (because the kernel needs to update it asynchronously when the state of the directory changes). Since MS-DOS has no "Find close" function, how do these alternate file systems know when it is safe to free the memory associated with the file search? ... Typically, a file enumeration is considered "abandoned" if it is not used for "a long time" or if too many pending file enumerations are in progress..." -- snip --
Perhaps what we need to do is get away from the way we keep only one FindFirstFile/FindNextFile search open at any one time, and instead keep one open for each non-abandoned DOS FindFirst/FindNext search. Presumably the Win32 FindFirstFile layer doesn't suffer from this problem (depth-first recursive directory deletion failing); guess I'd better check that. There are plenty of examples of people depending on it, e.g. http://www.codeproject.com/KB/files/deletedir.aspx
btw, I did check, rm.com does work for my little test case on XP on NTFS.