#404 Directory cache misbehaviour: ghost directories

0.74
open
nobody
None
1
2014-08-26
2014-05-09
Erkki Ruohtula
No

Background: I'm using DOXBox in a bit unusual way: to run proprietary and ancient non-interactive compilers on Windows 7. This involves a "wrapper" program that parses the original command line, then generates temporary BAT files that set up an environment, pre-process the source (to expand includes with file specs the ancient compilers cannot grok) and finally run the compiler. As part of this, temporary directories with unique names are generated for the preprocessed sources. These are under the current directory, which is "mount":ed in DOSBox so it is visible to the MS-DOS executable. After the executable has run, the temporary directory is normally deleted.
The problem: Sometimes (randomly, but often enough to be a nuisance) file accesses to the temporary directories failed, when several compilations were run in sequence in the same directory. Examining the state inside DOSBox, it looked like DOSBox was remembering the temporary directory name from the previous execution of itself. Eg. if the directory name was TEMP01 in execution 1 and TEMP02 in execution 2, sometimes DOSBos though that TEMP01 is in the directory during execution 2, even though it had been deleted after execution 1.
I know this sounds implausible. Browsing the online DOSBox sources, it looks like the directory cache is kept in memory only and should get recreated in every execution. My hypothesis is that all fields of the relevant object are not initialized in the constructor, and Windows leaks information from one execution to the next, so re-executing DOSBox rapidly in the compilation scripts sometimes maps the cache object to exactly the same memory as in the earlier incarnation. Far-fetched, I know.
Fortunately, I found a work-around: creating a dummy file in the directory from within DOSBox and then deleting it somehow re-freshes the cache, so the ghost directory no longer appears. My current wrapper uses this method. But of course if would be better if this hack was unnecessary.

Discussion

  • Jos Schaars
    Jos Schaars
    2014-05-17

    Your wrapper program is waiting for execution 1 to finish before it starts execution 2?

     
    • Erkki Ruohtula
      Erkki Ruohtula
      2014-05-19

      Yes. In fact one wrapper execution runs just one MS-DOS program. The wrappers in turn are started from a script or makefile.
      Since entering the ticket, it has occurred to me this might really be a Windows bug. The wrapper calls GetShortPathName() on the current path and uses the result as the working directory for the MS-DOS process. This happens before calling DOSBox. Inside DOSBox the shortened name is mapped to a drive letter by a script generated by the wrapper. Now it is possible Windows 7 blows the management of the short names, it is after all a bit rarely used feature these days. I will see if I can reproduce the ghost directory problem without DOSBox.

       
      • Jos Schaars
        Jos Schaars
        2014-05-19

        Why not use the long name inside DOSBox to map/mount the directory to a drive?
        (Also to test if it's a Windows 7 bug).

         
        • Erkki Ruohtula
          Erkki Ruohtula
          2014-05-20

          Good idea. I will try to see if that makes a difference when I get the time.

           
        • Erkki Ruohtula
          Erkki Ruohtula
          2014-07-31

          HI, I finally got around to testing what happens when the GetShortPathName() call is eliminated, and guess what: now it works without the dummy file workarounds. My conclusion is that the Windows API GetShortPathName() is broken and should never be used for anything.
          So we can kill this bug report.