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.