[Bug 17181] New: Winbench 96 disk test fails during recursive directory deletion; bug in INT21_FindFirst/FindNext?
http://bugs.winehq.org/show_bug.cgi?id=17181
Summary: Winbench 96 disk test fails during recursive directory deletion; bug in INT21_FindFirst/FindNext? Product: Wine Version: 1.1.13 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: dos AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
Install and run Ziff-Davis PC Benchmarks WinBench 96 (on the Winstone 32 cd-rom). Start it with cd .wine/drive_c/ZDBENCH/WB96 wine WB96 Get past the hangs described in bug 12267 by killing and restarting twice.
Run the "Disk Tests". Get past the abort
"A DOS file operation that was supposed to fail succeeded during the test. The following information is for ZDBOp use: Drive: C Operation: GetFileAttrib Script Location: 0d0b11 0 Pathname(s): C:~WBDM.TMP\ZDBENCH\WS96.B03\WORK\PDOX50"
by applying the patch http://www.winehq.org/pipermail/wine-patches/2009-January/068579.html
The test runs for a long time, then tries to delete its temporary directory, C:~WBDM.TMP, but fails with the dialog and the app aborts with
"A DOS file operation failed during the test. The following information is for ZDBOp use: Drive: C Operation: DeleteTestDir Pathname(s): SB, ??????????? Working Dir: ~WBDM.TMP Int 21 Function: 3a 00 CF: 1 Expected CF: 0"
Looking at the log, it seems as if Wine trips over its shoelaces when the app is doing its recursive directory list, and does not tell the app about one directory, C:~WBDM.TMP\MGA\CPANEL. As a result, the app doesn't delete its contents, and when the app then tries to delete C:~WBDM.TMP\MGA, it fails with 'directory not empty'.
INT21_FindHelper looks awfully tricky. It seems to have a loop to skip over some directory entries, and maybe this is firing improperly here. The code seems to date from 2003-11-14, mostly written by Eric Pouech in http://source.winehq.org/git/wine.git/?a=commit;h=8ca6cadab1ebb386f1dfa2e47c... and touched up by Alexandre same day in http://source.winehq.org/git/wine.git/?a=commit;h=adfa5e101fc2e01d4276c3f3ee...
http://bugs.winehq.org/show_bug.cgi?id=17181
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Summary|Winbench 96 disk test fails |Recursive directory deletion |during recursive directory |fails for multiple DOS apps; |deletion; bug in |bug in |INT21_FindFirst/FindNext? |INT21_FindFirst/FindNext?
--- Comment #1 from Dan Kegel dank@kegel.com 2009-01-29 15:35:56 --- Also affects Mark Adler's implementation of rm:
ftp://ftp.simtel.net/pub/simtelnet/msdos/dirutl/ma_rm14.zip
It's a 16 bit part-C, part-assembly app with source code, so it's very easy to follow what it's doing. You have to run it several times to fully delete a large hierarchy.
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #2 from Dan Kegel dank@kegel.com 2009-01-29 22:42:55 --- Easiest testcase is mkdir testdir mkdir testdir/dir1 mkdir testdir/dir2 wine rm.com /s testdir This fails to see dir2, so the delete of testdir fails.
It seems that the rmdir of dir1 messes with FINDNEXT's mind. FINDNEXT dutifully skips forward dta->count entries to get back where it was... but that's one too far now. rmdir dir1 has to decrement dta->count somehow if dir1 is before the mark. Fun!
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.
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #4 from Dan Kegel dank@kegel.com 2009-01-29 23:49:26 --- http://blogs.msdn.com/larryosterman/archive/2005/02/04/367259.aspx has some trivia about this, too.
OK, I think I've got this out of my system now. (I've spent too much of what was supposed to be a sick day looking at this...)
http://bugs.winehq.org/show_bug.cgi?id=17181
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #5 from Jerome Leclanche adys.wh@gmail.com 2010-08-06 19:14:54 --- +source (are ftp urls accepted in bugzilla's URL field?).
Dan, update on this bug? I'm getting this so i cant test: wine: Cannot start DOS application "Z:\home\adys\bin\wine\RM.COM" because vm86 mode is not supported on this platform.
http://bugs.winehq.org/show_bug.cgi?id=17181
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source URL| |ftp://ftp.simtel.net/pub/si | |mtelnet/msdos/dirutl/ma_rm1 | |4.zip
http://bugs.winehq.org/show_bug.cgi?id=17181
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #6 from Bruno Jesus 00cpxxx@gmail.com 2011-09-11 21:07:29 CDT --- This doesn't seem to be a problem anymore now that dosbox is being used.
I tested the RM.COM using the testcase from comment 2 and the 3 directories were removed correctly (inside dosbox).
So in my opinion this bug is fixed =)
Can anyone else retest or post other ideas?
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #7 from Dan Kegel dank@kegel.com 2011-09-11 21:23:54 CDT --- I'm still a bit unclear on the concept of how we support win16 apps. Those aren't handled by dosbox, are they? But they still use DOS file operations, right? So maybe the bug still exists for win16 apps.
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #8 from Bruno Jesus 00cpxxx@gmail.com 2011-09-11 22:39:20 CDT --- I see, I didn't realize the original problem was in a win16 app, I can't find it for download, do you have a link for the WinBench 96?
Or maybe is it possible to run rm.com without dosbox? Are there any flags to disable dosbox and run in pure wine?
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #9 from Dan Kegel dank@kegel.com 2011-09-12 08:42:39 CDT --- Grumble. Installer hangs now on exit, and the app won't start on a 64 bit natty due to https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/783622 I'll re-re-test on a different system shortly.
http://bugs.winehq.org/show_bug.cgi?id=17181
--- Comment #10 from Dan Kegel dank@kegel.com 2011-09-12 10:00:29 CDT --- To work around crash (also present on 32 bit natty), did wget http://mirror.pnl.gov/ubuntu//pool/main/f/fontconfig/libfontconfig1_2.8.0-2u... dpkg -i --force-depends libfontconfig1_2.8.0-2ubuntu1_i386.deb The app then crashes on start a little later, but rerunning it says it crashed while detecting processor, and allows you to skip the crash. The next crash is preceded by err:dosmem:DOSMEM_MapDosLayout Need full access to the first megabyte for DOS mode and the workaround is to open up a security hole by addding vm.mmap_min_addr = 0 to /etc/sysctl.conf and reboot. I can't reboot this system just yet, will test later today.
https://bugs.winehq.org/show_bug.cgi?id=17181
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|ftp://ftp.simtel.net/pub/si |ftp://ftp.pl.freebsd.org/vo |mtelnet/msdos/dirutl/ma_rm1 |l/rzm1/simtelnet/msdos/diru |4.zip |tl/ma_rm14.zip
--- Comment #11 from Austin English austinenglish@gmail.com --- http://www.filewatcher.com/m/ma_rm14.zip.12703-0.html austin@aw25 ~/oldbugs/17181 $ shasum ma_rm14.zip c706746c4dd10d1e4a737941ca93338f328db523 ma_rm14.zip austin@aw25 ~/oldbugs/17181 $ du -h ma_rm14.zip 16K ma_rm14.zip
In wine-1.7.12:
austin@aw25 ~/rm $ mkdir -p testdir/dir1 testdir/dir2 austin@aw25 ~/rm $ ls testdir/ dir1 dir2 austin@aw25 ~/rm $ wine RM.COM /s testdir fixme:storage:create_storagefile Storage share mode not implemented. fixme:storage:create_storagefile Storage share mode not implemented. fixme:iphlpapi:NotifyAddrChange (Handle 0xdbe8b0, overlapped 0xdbe8bc): stub wine: configuration in '/home/austin/.wine' has been updated. err:process:get_process_cpu L"winevdm.exe" uses unsupported architecture (0000) wine: Bad EXE format for Z:\home\austin\rm\RM.COM.
dosbox is not installed on this machine (fwiw).
https://bugs.winehq.org/show_bug.cgi?id=17181
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |35584
https://bugs.winehq.org/show_bug.cgi?id=17181
Bug 17181 depends on bug 35584, which changed state.
Bug 35584 Summary: wine can no longer execute rm.com (DOS application) https://bugs.winehq.org/show_bug.cgi?id=35584
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=17181
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED CC| |infyquest@gmail.com
--- Comment #12 from Vijay Kamuju infyquest@gmail.com --- DOS support is removed from wine from version 3.1. Hence marking as wont fix. Please use dosbox
https://bugs.winehq.org/show_bug.cgi?id=17181
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Status|RESOLVED |CLOSED
--- Comment #13 from André H. nerv@dawncrow.de --- closing wontfix
-
wine-bugs＠winehq.org