[Freedos-devel] FORMAT 0.91L Windows compat, "bug-keep FAT32 bug"

[Eric A. <eric@CoLi.Uni-SB.DE>]

Hi, some Windows compatibility results:

Windows 2000 pretents to be DOS 5.0 (!) so FORMAT fails to notice that
it should do drive locking. If you run FORMAT through CALLVER in FREECOM,
it tries to LOCK the drive but the request gets rejected (error 1). You
can ONLY format floppy disks with FreeDOS FORMAT in Windows 2000 and
probably only if you manually did the locking. Note that CALLVER 7.10 FORMAT
does not work with the default CMD shell, because CMD will refuse to run
under DOS 7.10 ... weird MS world!

In the DOS of Windows 98 SE, the values for "FileSystem Info Sector" and
"Backup Boot Sector" postition are both 0 (FORMAT rejects them as invalid)
although RBIL IntList 61 tells that "none" should be represented by 0xffff!

To make things even worse, Get_FS_Info detects FAT16 but clusters are > 65525L
on an 8 GB partition, so FORMAT realizes pretty late that the drive is FAT32.

...

I have used the collected feedback to add extra sanity checks and to
make the error messages a bit nicer. You can get the new incarnation of
format-0.91l.zip ("l" like in "lame") at
http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ ... as usual.

Really good question is what causes "sector 0 contains FS info sector
instead of boot sector after FORMAT under Win98se sometimes". There are
really enough sanity checks that should help to avoid that by now!?!?

A new logfile suggests that FreeDOS format is undecided between FAT16 and
FAT32 because access type is FAT32 but FAT1x size is nonzero!

Probably because a strange format has been created for it before.

The new upload is now VERY crowded with sanity checks, and when in doubt,
it enforces a proper FAT32 or FAT1x format rather than a "double" one.

All this would be easier if DEBUG could be used as FAT32 sector editor
already ;-). At least I tested with random data overwriting FAT1x boot
sectors, and FORMAT "survived" both for FAT12 and FAT16, did not save
unformat data (because of the implausibility of the random boot sector)
and was even able to UNFORMAT the drive after that (using an older version
of the unformat data - as told, it did not overwrite the existing unformat
data with the data of the filesystem with the random/broken boot sector).

As usual:
          No matter how foolproof it is, there will always be something
          out there which will break it because it is even more foolish.

I hope and think that that Win98SE thing is not Win98SE typical but is
an unfortunate property of FORMAT related to preserving broken FAT32 states.
Probably zapping the boot sector (e.g. with some FDISK maybe? Or of course
with dd if=/dev/zero bs=512 count=1 conv=notrunc of=/dev/victim ... but never
type the wrong victim for that!) would resolve the issue.

We will find out. Maybe you can test FAT32 formatting under Win9x DOS mode
and/or Win9x DOS box and check whether the created filesystems are okay.
If not, please use the /d (verbose debug messages) mode and store a log file:
format x: /v:fat32test /d >logform.txt
Do not quote the whole file, just the lines
(beginning) ... (beginning of mirror map writing or alternatively the error
message which tells why the mirror map is not written)
and
if mirroring is used, the lines which tell which the last FAT sector is and
which root dir sectors are mirrored (if none, tell about that)
and
"Creating File System" ... "Clearing FAT Sectors" (without the sector list!)
and
"Writing FAT1 Headers" ... "Clearing Root Directory" (without the sector list!)
and
the final statistics (after "Format complete")
If I say "without the sector list", I mean "do not quote that "99, 100, 101..."
kind of text, but do quote things like "Sectors 99 to 999" or "Sector -> 9".

Thanks for your help with debugging...



Eric.

PS: I would be happy to hear that FORMAT 0.91L *does* create proper FAT32
filesystems in FreeDOS and maybe even Win9x in general. If the abovementioned
Win98SE bug happens all the time, it would really give me a bad time :-/.