[Bug 17181] Recursive directory deletion fails for multiple DOS apps; bug in INT21_FindFirst/FindNext?

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17181





--- Comment #3 from Dan Kegel <dank at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.