Chkdsk identification of FAT 32 Drives is inconsistent

[Gregg Young]

In line 2 and 3 it is identified as UNIFAT and in line 4,5 & 10 as FAT 32

The current hard disk drive is: F: The type of file system for the disk is UNIFAT. The UNIFAT file system program has been started. FAT32: Unicode translate table for CP 850 loaded. FAT32 version 0.10.r277 compiled on Jun 13 2017 The volume label is TEST.

The Volume Serial Number is 1903-3D48.

The type of file system for the disk is FAT32.

[Valery V. Sedletski]

It is as designed. File system identifies itself as UNIFAT if /fat and/or /exfat switches are specified. This is to avoid confusion when fat32.ifs reports FAT16 volume as FAT32. Indeed, this is not a FS type, but an IFS identification. It is the FS_NAME export of an IFS and is returned by DosQueryFSAttach.

The type of file system for the disk is UNIFAT

is the DosQueryFSAttach result returned by CHKDSK.COM frontend program.

CHKDSK routine of uunifat.dll additionally autodetects the FAT type to be FAT12/FAT16/FAT32/exFAT, like this:

The type of file system for the disk is FAT32

[Gregg Young]

is the DosQueryFSAttach result returned by CHKDSK.COM frontend program.

DosQueryFSAttach needs to return the actual file system failure to do so breaks tools that need to know this information. This breaks FM/2 and the AN removables widget. FM/2 for example handles fat32 differently than fat so it is necessary that DosQueryFSAttach returns the actual file system. While fm/2 can be changed many of these tools cannot.

[Valery V. Sedletski]

The IFS name is UNIFAT and it is returned by DosQueryFSAttach. It is a global IFS variable, called FS_NAME, which identifies the IFS, but not the actual file system. I cannot return FAT12/FAT16/FAT13/exFAT because IFS name is UNIFAT (or FAT32, if /fat or /exfat are not specified). Or, do you mean I need to return FAT32, regardless of fliesystem (whether it is FAT12/FAT16/FAT32/exFAT). So, do you mean it is ok if FAT16 disk is reported as being FAT32?

[Gregg Young]

After scanning a fat 16 drive FM/2 no longer recognizes it as a valid drive (defaults to opening the directory menu instead of the drives menu). The directory names also disappear out of the drive tree It knows nothing about UNIFAT. Returning fat32 isn't much better because FM/2 sets different drive flag for it relative to fat 16. AN removables would be easy to fix but right now it shows the eject choice as x: <error> instead of x: <fat> or x: <fat32>.

Basically it will break anything that calls DosQueryFSAttach needing to know if the drive is fat. File Star (and every other file manager we don't have source for) comes to mind as a potential problem that can't be fixed but I haven't tried it. The problem with the ones that can be fixed is someone needs to do it. FAT32 would be better because it would be recognized. Perhaps it would be best to split this into 3 drivers. Thanks

[Valery V. Sedletski]

I can disable identification of the IFS as UNIFAT and return the FAT32 identification instead. But it can confuse someone seeing a FAT16 being shown as FAT32. Also, user mode tools should not handle different FS-es differently. FAT32 removable isn't any different than a JFS one. So, File managers should not distinguish between them. I could, for example, write a Netdrive plugin for reading FAT drives, and such drive should not be treated differently than a FAT drive handled by fat32.ifs or the kernel FAT driver. Isofs plugin can attach ISO images, which should be undistinguishable from CDFS.IFS CD's.

Why FM/2 needs to distinguish FAT16 and FAT32 drives? I think, this is wrong indeed. All FS'es should be handled the same way. Imagine I'll port new FS to OS/2 from different OS. Why needs FM/2 to know each FS? Do you need to update it each time a new FS is released? I think, it is better just treat all FS'es equally. Regarding the removables widget, I can't imagine why should it care which FS is on the removable drive. BTW, as users report, the widget only writes "error", but ejects FAT32 drives ok.

To split it to three drivers is not desirable too, because much code is common between FAT12/16/32/exFAT. It uses the same routines and why update three drivers in parallel if it could be updated only once?

[Valery V. Sedletski]

PS: I could also try returning "FAT" instead of "FAT32" for different FAT filesystems, but it won't help to distinguish between FAT16 and FAT32. BTW, if FM/2 needs this because the kernel FAT supports short filenames only, then in case of fat32.ifs, VFAT long filenames are supported in case of FAT12 or FAT16. So, identification of drive as "FAT32" will cause it to support long filenames, which is ok.

[Valery V. Sedletski]

And? FAT and FAT32 and JFS are all local. Too much superfluous essences. Why do it need to deistinguish between "Virtual drive", "ramdisk", "remote drive", "ZipStream"?

[Gregg Young]

Why FM/2 needs to distinguish FAT16 and FAT32 drives?

Fat drives show the longname ea if present as the file name something I don't want on fat32 but as you point out since you are providing VFAT support this shouldn't matter.

Why needs FM/2 to know each FS? Do you need to update it each time a new FS is released?

It doesn't need to know them but it gives the opportunity to tune performance. For example if I know that a drive is a netdrive drive I set it to turn off the drive stats since they are meaningless. Also the drive type assigns the drive icon. See driveflags.png

Why do it need to distinguish between "Virtual drive", "ramdisk", "remote drive", "ZipStream?"?

This is used to set the drive icons. It is also used to limit searches. Probably a couple of other things I don't remember right now. ZipSteam was added by the original author in the 1990s and could probably be removed.

While I would prefer that each type of fat was identified correctly I am fine with it being FAT32.

[Valery V. Sedletski]

Ok, I now disabled changing the IFS name to "UNIFAT". Now, since r282, it should report itself as "FAT32" again. Please look at the usual place: ​ftp://osfree.org/upload/fat32/.