MISTERFS.EXE *BUG*

[held]

It seems MISTERFS.EXE is not reporting free space to DOS. So programs that check for disk space will fail. I ran into that problem yesterday trying to debug something with MS-DOS debug. IIRC DOSBox "always reports 512MB 256MB free" unless its actually less to mitigate this. So this could be solved by returning a free space value that isn't zero.

Steps to reproduce this problem,
1. Start MISTERFS.EXE
2. Go to the mapped drive
3. Run DEBUG.EXE
- N MEMDUMP.BIN
- R BX
- 10
- R CX
- 0
- W 0:0
Not enough disk-space
- Q

[callanabrown]

The documentation says only to use MISTERFS to transfer files, not to actually run anything from that directory.

[held]

I'm not, although it could be interpreted that way , DEBUG.EXE is found in PATH, in my case C:\DOS.
So it breaks when writing a file to /shared because it thinks the disk has 0 bytes free.

[user7182]

Are you running MS-DOS 6.22 or older?

Because the shared file system returns up to 4GB with the DISKSPACE operation, it may not work with older DOS versions.

Checking disk space on different versions of DOS on my system (which has 8GB of actual free space), I had the same problem:
MS-DOS 6.22: 0 bytes
MS-DOS 7.1: 4,294,981,760 bytes
FreeDOS 1.3: 4095 Mega bytes free

I made a change to limit the total and free space reported to 2 GB and then I was able to run your debug commands on MS-DOS 6.22.

Here's the pull request with my proposed changes:
https://github.com/MiSTer-devel/Main_MiSTer/pull/574

[held]

Yes I am actually running MS-DOS 6.22, so thank you very much

EDIT:
I opened a thread on vogons.org because their knowledge is just astounding when it comes to these things:
https://www.vogons.org/viewtopic.php?f=31&t=86991

The default of 256 MB for an hdd is a lot of free space for much of the DOS era, but not so much that it can cause poorly-coded software to have numeric overflows or so when calculating. It's just an amount reported to satisfy typical free space checks, it's not actually tracked (increasing and decreasing as files are added, modified, or deleted) for local folder mounts. However, you can set the amount with the -freesize parameter of the MOUNT command -- see the README about that.

Basically, in order to run "most" programs 256MB is the preferred amount of "free space" reported to DOS.
But I understand the need of the -freesize parameter DOSBox uses. You never know when you need it

[callanabrown]

I'm not, although it could be interpreted that way , DEBUG.EXE is found in PATH, in my case C:\DOS.
So it breaks when writing a file to /shared because it thinks the disk has 0 bytes free.

I'm confused, you mention C:\DOS and /SHARED as if you have mounted /SHARED as C:, is that right? No program should eve be writing to /SHARED is my point.

I believe the point is you should have DOS installed on another image. /SHARED is only for transferring files to other images, not for use as your main drive.

[Caldor]

I'm not, although it could be interpreted that way , DEBUG.EXE is found in PATH, in my case C:\DOS.
So it breaks when writing a file to /shared because it thinks the disk has 0 bytes free.

I'm confused, you mention C:\DOS and /SHARED as if you have mounted /SHARED as C:, is that right? No program should eve be writing to /SHARED is my point.

I believe the point is you should have DOS installed on another image. /SHARED is only for transferring files to other images, not for use as your main drive.

This changed with the latest update though. Needs both AO486 updated and the new MiSTerFS file for AO486. This will make it possible to run games from shared and such. Still no support for long filenames though.

[held]

Yeah, this was a great step forward in my book