Hi, using FREETEST and WHICHFAT and FORMAT, I found some wrong kernel behaviour... Test setup: F: drive is 32.x MB diskimage drive in DOSEMU. Kernel 2035-32, FreeCOM 0.82pl3 ... The other tools can be found on my homepage.
Test: debug (a recent version with FAT32 support, F: is FAT32!) -lcs:100 5 0 1 -fcs:100 l 200 0 -wcs:100 5 0 1 "reboot" DOSEMU whichfat f: -> triggers critical error reading DOS area, "general failure" (FORMAT reports the same: Error code ??oc, where 0c means general failure) CORRECT error code would be 07, "no FAT filesystem". -> both RETRY (okay) and FAIL (wrong!) cause retry, no matter how often you try... -> when I select ABORT, then "returned" errorlevel will be 0. Okay. -> when I select IGNORE often enough, then DOS will start to believe that the drive is FAT16! WHICHFAT will return errorlevel 16. -> after that, FREETEST 5 f: and FREETEST 4 f: will return errorlevel 32 and 129 respectively: DOS obviously thinks that the drive is 32 (129/4) MBytes! This is correct but it is NOT correct to report that all this space is free. After unformatting the drive again (;-)), WHICHFAT properly reports that the drive is FAT32, and FREETEST properly reports that 17 (71/4) MBytes are free on the drive. Next, I do the same experiment with FAT12 diskimage drive D: (7-8 MB)... again, boot sector / BPB stays in buffers, so DOS first does not notice the problem. I "reboot" DOSEMU. WHICHFAT again reports FAT16 after a bunch of IGNOREs. According to FREETEST 7 d:, the drive is 186 (errorlevel) * 16 MB free space (2.9 GB, a theoretically impossible value as FREETEST uses the FAT1x "free space info" interface, as FreeCOM, so both are unable to report more than 2 GB free space in theory...). Whatever. The normal case would be not selecting IGNORE. I have to "reboot" DOSEMU again, because not even an LBACACHE SYNC or FDAPM fiddling would make DOS re-read the boot sector... When I use ABORT, both FREETEST and WHICHFAT "return" errorlevel 0, of course. After using FORMAT /z:unformat d: (I have taken a FORMAT /z:mirror d: before zapping the boot sector), D: is restored to normal operation. WHICHFAT reports FAT12 and FREETEST 5 d: and FREETEST 3 d: properly report errorlevel 7 and 120 respectively (120/16 = roughly 7.5 MB free: according to DIR 7892992 bytes). Drive is 2040 clusters of 4k each, 8355840 bytes, by the way. I think you get the pattern. Errors: * invalid boot sector should be reported as error 7, non-dos drive, not as error C, general failure * critical error processing "fail" seems to be impossible and leads to "retry" when boot sector contents are broken * should int 21.36 _really_ trigger a critical error? MS DOS seems to return "-1 sectors per cluster", which is the official value for "invalid drive" in that case. I think it does not show a critical error prompt. * When you ignore boot sector "critical error" (the CONTENTS are wrong, not the access! So "critical error" seems to be wrong here), then in FAT32 case FreeDOS will use the DEFAULT BPB as the CURRENT BPB. In other words, it will simulate an empty but formatted drive, but in FAT16 mode (I could not test with > 2 GB drive). Filesystem type information is lost, but size information is taken from partition information, it seems. In FAT12 case, FreeDOS seems to invent some wildly psychedelic CURRENT BPB... For FAT16 case (not explained in detail), things are very similar. After 6 * "ignore", FREETEST will report that 3 (finer scale: 247/64) MB are free. WHICHFAT will report FAT12. I assume that this means that FreeDOS invented a CURRENT BPB for a 3.8 MB drive and a FAT which is "all empty". Such data can only be interpreted as "FAT12 drive". So this explains why Bernd believed that WHICHFAT would report "unformatted" as "FAT12" - the real data is "unformatted" -> critical error -> either you have to abort WHICHFAT (errorlevel 0, no drive) or you ignore all errors. In the latter case, FreeDOS kernel + WHICHFAT combination will lead to either FAT12 or FAT16 being reported, depending on some probably random RAM contents. (The FAT16 diskimage test drive E: on my system is 32 MB, by the way...) PS: MS kernel + WHICHFAT + unformatted drive = errorlevel 1 (no local drive) according to Bernd. This is also returned if the drive letter is beyond valid range (according to int 21.0e, done after int 21.19), or if the drive FAT32 processing unexpectedly fails. If - according to int 2f.150b - the drive is a CD-ROM one, errorlevel 0 is returned. PPS: This means that we have the QUESTION "how do I distinguish a non-existing drive letter from an unformatted drive"? Probably "if drive letter below LASTDRIVE then it is always existing, and if int 21.36 reports -1 sectors per cluster then it is an unformatted drive"??? Thanks for the feedback already! Eric. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
