SVN rev 298: exFAT formatted media shows wrong filesystem type in WPS, files do not show up on commandline

[erdmann]

1) formatted a USB stick as exFAT under Windows. It is a partitioned stick.

2) enabled exFAT support in FAT32.IFS by specifying /exfat switch

3) copied some files via WPS onto the stick.

I can see and access the files via WPS. However the drive's details view shows "FAT32" as the filesystem (it was my expectation that it would show "exFAT").
When I run a chkdsk via the drive I get this:

[h:\]chkdsk h: /F
The current hard disk drive is: H:
The type of file system for the disk is FAT32.
The FAT32 file system program has been started.
FAT32: Unicode translate table for CP 437 loaded.
FAT32 version 0.10.r298 compiled on Jul 28 2017
The Volume Serial Number is F8D9-E086.
The type of file system for the disk is exFAT.

CHKDSK is checking fats :Ok.
CHKDSK is checking files and directories...
CHKDSK is searching for lost data.
CHKDSK has searched 100% of the disk.
The correct free space is set to 122759 allocation units
     3928512 kilobytes total disk space.
          32 kilobytes are in 1 directories.
          96 kilobytes are in 3 user files.
           0 bytes in 0 hidden files.
          32 kilobytes are in extended attributes.
     3928288 kilobytes are available for use.

       32768 bytes in each allocation unit.
      122766 total allocation units.
      122759 available allocation units on disk.

0% of the files and directories are fragmented.

This is somewhat confusing as first it is claimed that the filesystem is FAT32 whereas the second message claims it is exFAT.

However the most annoying problem is that no files are listed when I do a "dir" on a commandline. This is what I get from an OS/2 commandline:

[D:\]dir h:

Volume in drive H has no label.
The Volume Serial Number is F8D9:E086.
Directory of H:\

SYS0111: The file name is too long.

A 4OS2 commandline will give a different error but in any case, no files will be shown even though the WPS shows them just fine:

[d:\]dir h:

 Volume in drive H is unlabeled      Serial number is F8D9:E086
SYS0002: The system cannot find the file specified. "H:\*"
               0 bytes in 0 files and 0 dirs
   4.022.566.912 bytes (3.836MB) free

[Valery V. Sedletski]

It is as expected. "FAT32" is what DosQueryFSAttach returns as a filesystem driver name. It is the same as specified in the "FS_NAME" export of the IFS. In other words, it is a filesystem driver name, not a real FS name. The same was with vfat-os2.ifs, which supported readonly NTFS in addition for VFAT. The FS name was vfat everywhere. Here I cannot do very much about that. As you noticed, CHKDSK shows "exFAT" when it determines the exFAT filesystem. But there is also

The type of file system for the disk is FAT32.

in the beginning, which is written by chkdsk.com frontend program. That is determined by DosQueryFSAttach and is the same as displayed in "Info" panel of any file manager (including WPS).

Previously, I tried to identify the filesystem as "UNIFAT" in FS_NAME, if /fat or/and /exfat switches are specified. This is to avoid confusion, when FAT12/FAT16/exFAT filesystems are displayed as FAT32. But some programs, like FM/2, expect filesystem name to be "FAT32", and process FAT32 specially. So, I needed to return the "FAT32" identification back. So, I cannot do much with that. Just remember that it is not the real FS name, but the name of FS driver, which is FAT32. (I need to add this to FAQ).

PS: I acknowledge that with cmd.exe, "SYS0111: Filename too long" appears. But with 4OS/2 I see the contents fine. Everything is displayed by the "dir" command. Maybe, your disk is empty?

[Valery V. Sedletski]

2Lars: Which 4OS/2 version are you using? My version shows everything well... FC/2 and WPS shows files ok too.

[Valery V. Sedletski]

Looking into f32mon debug messages, I can see that cmd.exe calls FS_FINDFIRST with usLevel == FIL_QUERYEASIZEL. Looking into FIL_QUERYEASIZEL-specific code section, I see the following piece of code:

                     if (*pcbData < sizeof (FILEFNDBUF4L) + strlen(szLongName))
                        {
                        return ERROR_BUFFER_OVERFLOW;
                        goto FillDirEntryExit;
                        }

I suspect that cmd.exe knows nothing about FIL_QUERYEASIZEL. It expects a smaller structure with ULONG's (FILEFNDBUF2, but not FILEFNDBUF4L), instead of ULONGLONG's in place of file sizes. So, I have no idea, how can I solve this. Only disable the "large files" option, maybe :(. But how then cmd.exe lists JFS volumes?

[Valery V. Sedletski]

Ok, I acknowledge that with 4OS/2 from eCS 2.2 I see the same error you have. Why they differ so much?

PS: With this 4OS/2 version the problem is the same as with cmd.exe: an ERROR_BUFFER_OVERFLOW == 111 is returned from FS_FINDFIRST.

PPS: FC/2 and my version of 4OS/2 use FIL_STANDARDL, instead of FIL_QUERYEASIZEL in cmd.exe and eCS version of 4OS/2, hence the difference. So, looks like FIL_QUERYEASIZEL doesn't work.

[Valery V. Sedletski]

Hehe, it was like this for FIL_QUERYEASIZEL, and only for it:

   if (*pcbData < sizeof (FILEFNDBUF4L) - CCHMAXPATHCOMP + strlen(szLongName) + 1)
      {
      return ERROR_BUFFER_OVERFLOW;
      goto FillDirEntryExit;
      }

-- I actually forgot to delete CCHMAXPATHCOMP. When I deleted, it worked ok. CCHMAXPATHCOMP was left here since you've fixed an EA problem and I forgot to delete CCHMAXPATHCOMP in exFAT code only for FIL_QUERYEASIZEL. Everything was simple :)

[Valery V. Sedletski]

1) formatted a USB stick as exFAT under Windows. It is a partitioned stick.

BTW,

format o: /fs:exfat /v:test /c:256

should work from OS/2 too. FORMAT and CHKDSK now support all flavours of FAT: FAT12/FAT16/FAT32/exFAT.

Also, with /fat switch, vfdisk.sys and vdisk.sys mount to fat32.ifs fine. The only problem remained when trying to do loaddskf floppy.dsk x: to vfdisk virtual floppy (and to physical floppy too). The problem is because after loaddskf calls the DSK_SETDEVICEPARAMS, the kernel overwrites vpfsd with FAT-related data, and when fat32.ifs detects this, it displays a panic message. Savedskf.exe works fine, though. Otherwise, virtual and physical floppies works with fat32.ifs fine. With svdisk.sys, there is a problem similar to a loaddskf problem, i.e. it panics/traps after calling DSK_SETDEVICEPARAMS ioctl too.

Also, except for my experiments with loppies, I created a FAT16 filesystem with 2048 bytes per sector and wrote it onto a CDRW disk. Fat32.ifs mounts such FAT-formatted CDRW fine too.

[Valery V. Sedletski]

I committed svn revision r299. Here there are the following fixes: 1) fixed FIL_QUERYEASIZEL in FS_FINDFIRST/FS_FINDNEXT on exFAT, so, cmd.exe now displays directory listings 2) now loaddskf/savedskf can be used on physical or virtual floppies. Now vdisk/vfdisk/svdisk work fine with fat32.ifs. 3) TranslateName is implemented for exFAT. However, this introduces another bug: "wp root. sf" file is not created on an exFAT volume. Fixing this is in progress. Also, there is a bug with copying a file to an exFAT volume with WPS. The file gets created with zero size and then copying fails. The "copy" command and FC/2 work fine, however.

[erdmann]

1) about filesystem name: I just realized that this is a duplicate of report #50.
OS/2 was designed to only support one filesystem per IFS driver, as you correctly pointed out there is only one FS_NAME variable to hold the filesystem name.
It was a bit unfortunate that you jammed exFAT support and FAT32 support into the same driver (you could have written a common static library and used that from 2 different drivers ...).
But OS/2 in general surely has more severe problems than this one. I'll take it for granted ...

2) about missing file listing from a commandline: yes, the FIL_QUERYEASIZEL fix for exFAT in SVN rev 299 fixes the problem. The directory contents will now list just fine from a commandline.

Thanks ! You can close this bug.

[Valery V. Sedletski]

OS/2 supports several filesystems with one IFS. It is supported by vfat-os2.ifs or Netdrive, for example. Just don't rely on an IFS name being the same as FS name. It is a bad practice to treat some FS-es specially. They all should be equal to programs. FAT12/16/32/ex are just the same from the IFS point of view. The features of each FS are just the same, and no need to distinguish between them. I'd like to name it better as "FAT" or "UNIFAT", but some bad-designed programs, like FM/2, don't show correct menues on FAT32 filesystems, if not "FAT32" is returned by DosQueryFSAttach. But showing it as "FAT" (or "UNIFAT") will avoid confusion. But unfortunately, I need to preserve compatibility with such programs. To create a common library and link it with three identical IFS-es with different name is bad too. Why it is needed? Only to see different names in the "Info" panel? As I already said, FS_NAME is intended as an IFS identification, but not as a filesystem name. BTW, windows does not distinguish between FAT12/FAT16/FAT32. It calls all three "FAT". But it has separate exFAT IFS. It is just because it was written by different people from scratch. But I based exFAT support on FAT32 support. Indeed, there's many common with FAT12/16/32/ex. Creating separate IFS'es will require unneeded doubling of the same code.

[erdmann]

Problem with displaying file list for exFAT formatted media is fixed with SVN rev 299.