[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(a)winehq.org ReportedBy: dank(a)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... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 Dan Kegel <dank(a)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(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #2 from Dan Kegel <dank(a)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! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #3 from Dan Kegel <dank(a)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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #4 from Dan Kegel <dank(a)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...) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #5 from Jerome Leclanche <adys.wh(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source URL| |ftp://ftp.simtel.net/pub/si | |mtelnet/msdos/dirutl/ma_rm1 | |4.zip -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #6 from Bruno Jesus <00cpxxx(a)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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #7 from Dan Kegel <dank(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #8 from Bruno Jesus <00cpxxx(a)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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #9 from Dan Kegel <dank(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17181 --- Comment #10 from Dan Kegel <dank(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=17181 Austin English <austinenglish(a)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(a)gmail.com> --- http://www.filewatcher.com/m/ma_rm14.zip.12703-0.html austin(a)aw25 ~/oldbugs/17181 $ shasum ma_rm14.zip c706746c4dd10d1e4a737941ca93338f328db523 ma_rm14.zip austin(a)aw25 ~/oldbugs/17181 $ du -h ma_rm14.zip 16K ma_rm14.zip In wine-1.7.12: austin(a)aw25 ~/rm $ mkdir -p testdir/dir1 testdir/dir2 austin(a)aw25 ~/rm $ ls testdir/ dir1 dir2 austin(a)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). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=17181 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |35584 -- 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.
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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=17181 Vijay Kamuju <infyquest(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED CC| |infyquest(a)gmail.com --- Comment #12 from Vijay Kamuju <infyquest(a)gmail.com> --- DOS support is removed from wine from version 3.1. Hence marking as wont fix. Please use dosbox -- 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.
https://bugs.winehq.org/show_bug.cgi?id=17181 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv(a)dawncrow.de Status|RESOLVED |CLOSED --- Comment #13 from André H. <nerv(a)dawncrow.de> --- closing wontfix -- 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.
participants (1)
-
wine-bugs＠winehq.org