MISTERFS.EXE *BUG*

held
Posts: 209
Joined: Sun Sep 26, 2021 2:18 pm
Has thanked: 27 times
Been thanked: 31 times

MISTERFS.EXE *BUG*

Unread post by 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
Posts: 85
Joined: Thu Jul 30, 2020 1:05 pm
Has thanked: 14 times
Been thanked: 21 times

Re: MISTERFS.EXE *BUG*

Unread post by callanabrown »

The documentation says only to use MISTERFS to transfer files, not to actually run anything from that directory.
held
Posts: 209
Joined: Sun Sep 26, 2021 2:18 pm
Has thanked: 27 times
Been thanked: 31 times

Re: MISTERFS.EXE *BUG*

Unread post by 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
Posts: 26
Joined: Sun Nov 21, 2021 3:30 pm
Has thanked: 22 times
Been thanked: 60 times

Re: MISTERFS.EXE *BUG*

Unread post by 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
Posts: 209
Joined: Sun Sep 26, 2021 2:18 pm
Has thanked: 27 times
Been thanked: 31 times

Re: MISTERFS.EXE *BUG*

Unread post by 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
On VOGONS.ORG ripsaw8080 wrote: Sun Mar 20, 2022 5:46 pm 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 :D
callanabrown
Posts: 85
Joined: Thu Jul 30, 2020 1:05 pm
Has thanked: 14 times
Been thanked: 21 times

Re: MISTERFS.EXE *BUG*

Unread post by callanabrown »

held wrote: Thu Mar 17, 2022 7:40 pm 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.
User avatar
Caldor
Top Contributor
Posts: 930
Joined: Sat Jul 25, 2020 11:20 am
Has thanked: 112 times
Been thanked: 111 times

Re: MISTERFS.EXE *BUG*

Unread post by Caldor »

callanabrown wrote: Mon Mar 28, 2022 2:30 pm
held wrote: Thu Mar 17, 2022 7:40 pm 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
Posts: 209
Joined: Sun Sep 26, 2021 2:18 pm
Has thanked: 27 times
Been thanked: 31 times

Re: MISTERFS.EXE *BUG*

Unread post by held »

Yeah, this was a great step forward in my book :D
Post Reply