Maybe interesting to you:

When I try to run "pc-shell" (the norton commander equivalent of the pctools) in dosbox (today's cvs-build, I downloaded it from "dosbox cafe", your patch already added), there is a message like "fat error" or something. This error message is the same in 0.65. So I think your patch has not yet resolved the problem completely.

This patch is related to disk image mounting only, in case of pc-shell (and scandisk) some dos behavior is missing. I tried to implement a bit of it but it revealed more and more missing stuff 😀

nevermind, just wanted you to know... .

Accessing the fat will never work for regularly mounted drives,
only for booted disk images. It might be possible for non-booted
disk images, but that's pointless.

About the patch: thanks for the findings, just the first one
doesn't seem to be neccessary for me. Even if the condition
(curSectOff>0 && loadedSector) is hit, the information is
already written in a previous cycle, or does it occur in some
special situation?

Well I wouldn't say it's pointless if I could run scandisk for images in Dosbox directly.
The problem with data not written is a bit deeper inside, if the app does a seek after a write (Norton Commander really likes to do that) then the data in the buffer is lost. Files < 512 bytes will have uninitialized data in them and larger files don't have the tail written.
There are also other bugs, clusters are appended to the file if there isn't a need yet(in case filesize%clustersize==0), so scandisk finds mismatching sizes, and sometimes the MBR gets overwritten.

h-a-l-9000 wrote:

...and sometimes the MBR gets overwritten.

I sure hope that can only happen to booted disk images or regularly mounted images... 😜 😁

Ronald

It shouldn't happen to booted disk images 😉 because the booted OS took over control of the disk.

> if I could run scandisk for images in Dosbox directly.

It is highly recommended to not use ANY program that directly
access the disk if no real dos is booted. There are too many
stub tables which gives in almost all cases wrong results for
those type of programs.
The disk image mounting is intended for copying files from
other mounted drives easily.

> Norton Commander can't delete a not empty directory because they
> do a findnext after a failed findfirst and get a rouge file that way

Something with the search IDs gets wrong, they're doing a findfirst,
then a few different findfirsts (for some nc file), and then continue
the first findfirst. This last findnext flags an error for local_drive,
but succeeds for drive_fat for some reason. The dta.SetDirID(0); would
have to be replaced, yet the ID is used to indicate the file position
in that search.

I'll committ the patch by times, thanks again 😀

> The dta.SetDirID(0); would have to be replaced,
This looks like it would be duplicated code with drive_cache...

Here are two mounting sanity checks.

> This looks like it would be duplicated code with drive_cache...

The drive_fat doesn't use the drive cache at all. It can be noticed
in that the files aren't sorted when typing dir on a disk image
(if the files aren't stored in name-sorted order).
The problem seems to be that the searches are done relative to
cwdDirCluster (see the call to FindNextInternal in FindFirst()).
Should be fixed now as well.

> Here are two mounting sanity checks.

Changed them to not cause the image loading to fail, as there
seem to be some images with odd/nonstandard geometry around.

I mean the CFileInfo implementation in DOS_Drive_Cache. I assume something similar would be needed in fatDrive.

About the sanity checks: such broken images wouldn't load on a real computer. The BIOS won't touch a MBR that doesn't have the 55AA. If such an image mounted at all then probably because dosbox overwrote the mbr with the partition data as zero and the startSector = 63 was used. (happened to me too)

some ultima install disk has no 55AA in the mbr

A floppy disk has a boot sector but no mbr

Still there's no reason why there shuldn't exist a bios that ignores the
id like most bioses do for boot sectors.
You'll surely know soon enough if somebody mounted a broken disk image.

Does the copying of system files not work, or is it copying
of hidden files? For me the latter is the case, as the hidden
flag is missing in fatDrive::getFileDirEntry and i don't see
any reason why it shouldn't be there (that is at
SetupSearch(0,0x5,findFile))

The files in question are io.sys and msdos.sys which have system, read-only and hidden attributes set.

Commenting out in FindNextInternal

1/* Always find ARCHIVES even if bit is not set  Perhaps test is not the best test */
2	if(~attrs & sectbuf[entryoffset].attrib & (DOS_ATTR_DIRECTORY /*| DOS_ATTR_HIDDEN | DOS_ATTR_SYSTEM*/) )  goto nextfile;

lets me copy these files.

yeah we are a bit "suspicious" about copying system and hidden files.

btw the mbr overwriting is caused by lines like
currentSector = myDrive->getAbsoluteSectFromBytePos(firstCluster, seekpos);
(especially in seek).
getAbsoluteSectFromBytePos can return 0 on faliure and if a write is done after such a call sector 0 = mbr will be overwritten.

> The files in question are io.sys and msdos.sys which have
> system, read-only and hidden attributes set.

Yes, that's why i asked if you are sure that it's the system
flag, as this one doesn't cause any trouble for me.
See the posting above, and see what happens if you change
the 0x5 into a 0x7 (works for me).

> getAbsoluteSectFromBytePos can return 0 on failure

That's indeed pretty bad, any idea when this happens? Seems to
only affect fatFile::Seek, maybe changing it to the following
would help:
Bit32u sector = myDrive->getAbsoluteSectFromBytePos(firstCluster, seekpos);
if (sector) currentSector = sector;
else return false;
though normally a seek never fails (only the following write/reads).