Trap D usb floppy drive

[abwillis]

Attempting to do a directory listing on a USB floppy drive results in a Trap D in fat32.sys. I set /fat:o in the config.sys which apparently stopped fat32.sys from mounting the drive as I then did not get te trap D.

[abwillis]

While the /fat:o stopped the trap, it still caused a problem copying files off of the floppy. chkdsk, as well as larsen commander, sees the file system as FAT32. rem out the ifs and then the files copied and the file system was seen as FAT.

[Valery V. Sedletski]

Tried an ISA floppy, it works fine. VDISK.SYS/VFDISK.SYS virtual floppy drivers are now working too (will upload the binaries soon). Will test the USB floppy too. Are you sure that specifying /fat:o indeed help? I tested it and it appears that it still mounts all fat and exfat disks if /fat32:<drive letters> mask is not set. I fixed this behaviour, now it works. Will upload the binaries soon.

Could you take a f32mon.exe log when copying files from floppy? (and when it is trapping. For that, you need to start f32mon.exe and take a COM port log. Do you have a null-modem cable and a laptop?)

The IFS always show the file system as FAT32, it is normal. Indeed, it is the FS driver name, not the real filesystem name. It is the same for FAT12/FAT16/FAt32/exFAT. Only CHKDSK shows the real FS name:

[l:\src\fat32\trunk\src\bin\os2\dll]chkdsk h:
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 866 loaded.
FAT32 version 0.10.r242 compiled on Apr 29 2017
The volume label is FAT16.
The Volume Serial Number is 15FC-1550.
The type of file system for the disk is FAT16.

CHKDSK is checking fats :Ok.
CHKDSK is checking files and directories...
.. entry in H:\md is incorrect! (1 0)
CHKDSK is searching for lost data.
CHKDSK has searched 100% of the disk.

  1897267200 bytes total disk space.
    16187392 bytes in 156 hidden files.
    32636928 bytes in 993 directories.
    44466176 bytes in extended attributes.
  1509130240 bytes in 15062 user files.
   294879232 bytes available on disk.

       32768 bytes in each allocation unit.
       57900 total allocation units.
        8999 available allocation units on disk.

0% of the files and directories are fragmented.

Note the

The type of file system for the disk is FAT16.

line.

[Valery V. Sedletski]

Tried the USB floppy, works quite well, though, slow, as well as ISA floppy. I see no trap and copying files from a floppy works too. Which problems do you mean, occuring when copying files?

[abwillis]

Interestingly, /fat:a also prevents the trap d. The failures with copy with /fat:o turns out to be caused by bad media. The kernel fat will pass an error: SYS0023: Data error (cyclic redundancy check). The fat32.sys driver will result in the copy program to crash, if using 4os2 copy then 4os2 crashes, if cp.exe then cp.exe will crash.

[Valery V. Sedletski]

Hm, interesting. Could you, please, run f32mon.exe before copying, and show me the log? Is o: a flash disk or something on your machine? Which switches to fat32.ifs have you specified? Is /fat32:<something> specified too? Is the kernel FAT mounted if /fat:o or /fat:a is specified? (Look at info panel in FC/2 or Larsen Commander (never used it, though))

There was an incorrect logic which caused a: not mounted if /fat:o is specified, hence no trap (kernel FAT mounted). But specifying /fat:a should not cause a: to be not mounted. Are you sure /fat:a helps too?

[abwillis]

The attachment is with /fat:a. I do not have an O: drive, which is why I chose it. I was going off the idea that if I explicitly set the IFS to /fat for a specific drive it would not be used on other drives and thus chose a drive that did not exist.

[abwillis]

trap d jpg

[abwillis]

I noticed that Lars' uploaded a new vfdisk for fat32 compatibility, even though it was not in use, I installed it just to make sure it was not involved in this trap. I still get the trap d if I do not have /fat parameter. Pulling this entry up I see there are some new updates in svn... I will build with those and verify if I still get the trap.

[abwillis]

With SVN 248 it does not trap without the /fat. It appears to be using the kernel FAT as chkdsk is showing FAT and not FAT32.

[abwillis]

OK, adding /fat:a verifies that without /fat it now behaves as I would expect and uses kernel and does not trap. The Cyclic Redundancy Check failure causing the app that is being used when it is encountered is a separate issue from the trap... I can open a separate ticket for it if desired as the trap d is resolved.

[Valery V. Sedletski]

I still get the trap d if I do not have /fat parameter.

Trap if no /fat is specified? -- You said previously about /fat:o (where O: is anon-existing drive letter). No /fat and /fat:o previously behaved differently. Without /fat it should not mount FAT12/FAT16 drives at all, so fat32.ifs should not touch the floppy at all.

With SVN 248 it does not trap without the /fat. It appears to be using the kernel FAT as chkdsk is showing FAT and not FAT32.

It should be like this before r248 too. But with /fat:o maybe, hypothetically.

OK, adding /fat:a verifies that without /fat it now behaves as I would expect and uses kernel and does not trap.

Ok, so the trap is gone

The Cyclic Redundancy Check failure causing the app that is being used when it is encountered is a separate issue from the trap... I can open a separate ticket for it if desired as the trap d is resolved.

This may be. But I think, no need to create a separate issue. We will work it out here.

[Valery V. Sedletski]

0003:f249 it is trapped somewhere in memcpy, because source pointer was NULL. No idea, where it did called from. Probably, it is trapped on mount. Very strange, why it did trapped. In #42 it did trapped in memcpy too. Maybe, it was the same problem.

[Valery V. Sedletski]

2abwillis: Please take this fat32.ifs: ​ftp://osfree.org/upload/fat32/test/abwillis1.zip, install it over r248 and take a f32mon log. I added some debug messages.

According to the log,

221	P:63 T:18 D:0 T:52:335 FS_READ, 61440 bytes at offset 0
222	P:63 T:18 D:0 T:52:335 GetFatAccess: GetNextCluster
223	P:63 T:18 D:0 T:52:335 ReleaseFat
224	P:63 T:18 D:0 T:52:337 ERROR: Cluster 65550 (1000e) does not exist on disk A:
225	P:63 T:18 D:0 T:52:337 FS_READ returned 27 (0 bytes read)

it got the cluster value of 0x1000e from GetNextCluster. Too big value for FAT12. We need to understand, why.

[abwillis]

Replying to valerius:

Trap if no /fat is specified? -- You said previously about /fat:o (where O: is anon-existing drive letter). No /fat and /fat:o previously behaved differently. Without /fat it should not mount FAT12/FAT16 drives at all, so fat32.ifs should not touch the floppy at all.

Sorry for the confusion... I never tried just /fat, I was using it generically here in that /fat:o and /fat:a both fixed it which means /fat by itself probably would have also worked and I was using /fat as a shorthand for what I reported. What trapped was when no use of /fat:o or /fat:a (and by deduction but not test /fat).

[Valery V. Sedletski]

I see no additional messages in this log. Did you installed this IFS over: ​ftp://osfree.org/upload/fat32/test/abwillis1.zip? It looks, no.

[abwillis]

OK, I unzipped into the right place but did not expect the files to be in a directory so it wasn't using the right one. Uploaded log with the correct IFS.

[Valery V. Sedletski]

Ok, thanks, now I see it. So, the wrong cluster goes from FS_OPENCREATE. All FAT12 entries are intended to be truncated to 12 bits, but this value exceeds 12 bits. I suspect it was 0x1000e originally in the directory entry, so it did not truncated to 12 bits. Then please, test this new build: ​ftp://osfree.org/upload/fat32/test/fat32-0.10-r248-os2.zip. It has some more messages added, plus updated to the current version. Fat32.ifs now will report itself as UNIFAT, instead of FAT32, to avoid confusion with FAT12/FAT16 drives being shown as FAT32. What do you think, is this name good enough? Or, maybe any other name suggestions?

[Valery V. Sedletski]

I suspect that you have a file with EA's. In FAT32, M$ reused "reserved" EA pointer bytes as high word of a cluster number, so, I need to zero-out the high word on FAT12/FAT16, which I forgot to do (the code remained the same from FAT32 support). So, I am clearing these high words on FAT12/FAT16 now. I reuploaded the file under the same name, please test.

[abwillis]

I suspect the problem is related to a problem on the media. With the kernel fat I get the Cyclic redundancy check at the point that the copy crashes. I suspect, there needs to be a return code of some sort that maybe is passing back NULL causing the calling app to crash but that is of course speculation.

[Valery V. Sedletski]

Previously. there was an incorrect cluster number, 0x1000e. But now it reads all sectors ok, until sector 215 (because I cleared the bits above 12-th one in the cluster number), and then reading this sector fails:

ERROR: ReadSector of sector 215 (0 sectors) failed, rc = 23

ERROR_CRC == 23 is returned too, as with the kernel FAT. So, FC/2 does not crash on kernel FAT? It seems, it should crash too if the IFS is returning this error code. At least, I see that FC doesn't expect it and crashes if it gets it. It does not trap, but it gets an unexpected error and quits. Maybe, I need to return some other error code, though. Please, check which error code (or a message number) is written by FC/2 when this error occurs.

[abwillis]

I have copied via 4OS2 copy command, cp.exe from coreutils installed via rpm, and larsen commander. I don't have FC/2 to try. I know specifically what 4OS2 copy does when using kernel FAT as it is the error I posted previously, SYS0023: Data error (cyclic redundancy check). With the fat32.ifs, instead of showing the error, 4OS2 will just crash giving no indication as to the problem, or if you were not watching it to see the window close, even an indication that there was a problem. Once would have thought that return of the RC code would have been what was being checked.

[Valery V. Sedletski]

It looks like fat32.ifs has not read/write error handling. I.e., currently we just return errors like ERROR_CRC or ERROR_SECTOR_NOT_FOUND to the calling program. But this usually means that we have a bad sector encountered. In theory, we need to mark it as bad and exchange to another spare sector. (I suspect, we should zero it out, and file will then be corrupted.). I need to try adding such error handling.

[Valery V. Sedletski]

It appears that fat32.ifs calls FSH_CRITERR to signal a hard error to harderr.exe and show an error message on most errors. I have AUTOFAIL=YES on my machine, so I don't see any error messages and popuplog.os2 contains no errors too. So, if autofail is enabled, the program is just silently terminates without any error. This is bad. So, I need just to return error code, instead of raising the hard error.

[Valery V. Sedletski]

Now hard errors are no more signaled to harderr.exe, so it should be no FC/2 or WPS crashes in case an error is returned.

[abwillis]

With /fat I now get Cyclic Redundancy Check message instead of the app closing.

[Valery V. Sedletski]

Ok, so it now works as intended.