diff options
Diffstat (limited to 'sftsr.c')
| -rw-r--r-- | sftsr.c | 20 |
1 files changed, 18 insertions, 2 deletions
@@ -377,7 +377,7 @@ static vboxerr close_openfile(unsigned index) { vboxerr err; - dlog_print("close_openfile "); + dlog_print("close openfile="); dlog_printu(index); dlog_endline(); @@ -803,7 +803,6 @@ static void handle_rename(union INTPACK __far *r) translate_filename_to_host(&shflstr.shflstr); // Reusing shfldirinfo buffer space here for our second filename - // Hoping no one does concurrent find_next and rename copy_drive_relative_filename(&shfldirinfo.dirinfo.name, dst); translate_filename_to_host(&shfldirinfo.dirinfo.name); @@ -1109,6 +1108,23 @@ static void handle_find_first(union INTPACK __far *r) clear_sdb_openfile_index(&data.dossda->sdb); } + // We will still leak the directory handle if the program stops calling + // FindNext before reaching the end of the directory, e.g. if it expects + // a specific file. But why would a program use a wildcard search just to + // check the existence of a particular file? + // Hopefully this is a rare situation and we don't leak too many fds. + + // Naturally, Windows 3.x's Winfile does exactly what is described above. + // On mkdir, it will create a testdir.tmp file on the new directory, + // then proceed to findfirst "*.*" on it and expect the testdir.tmp file, + // never to call findnext again. + // Cue hack to avoid leaking one dirfd for each mkdir... + if (_fmemcmp(data.dossda->found_file.filename, "TESTDIR TMP", 8+3) == 0) { + dlog_puts("win3.x testdir detected"); + close_openfile(openfile); + clear_sdb_openfile_index(&data.dossda->sdb); + } + clear_dos_err(r); } |