Dirty flag not cleared after manual chkdsk pass

[Lewis Rosenthal]

Inserting USB media marked dirty results in the media being mounted anyway. Running chkdsk /f against the media results in a successful chkdsk pass (according to the screen output) but the dirty flag is left unchanged (according to DFSee 13.3).

FAT32.IFS version is 0.10alpha7 (UFAT32.DLL 10-16-2016)

Marking high priority as we need to ensure that we can differentiate between clean and dirty media which is mounted after boot (autocheck is not an option for removable USB media, as the USB stack initializes too late).

[erdmann]

Hallo Lewis,

I think you should reget the ZIP file. My FAT32.IFS file is dated 10-20-2016.
I just ran it against 2 dirty FAT32 volumes and DFSee showed them as CLEAN thereafter.

[Lewis Rosenthal]

Hi, Lars...

I wonder what the difference is between us.

DFSee says:

DFSee OS/2   13.3 : Executing: part -q -a 6                                    
                                                                               
DFS partition  Id : 06  disk nr : 5  = FixedDisk Diskgeo = Cyl:    7 H:255 S:63
 System Indicator : 0x0c       = FAT32-Ext     UNIX devicename: /dev/hde1      
 FileSyst. format : FAT32                     Windows BOOT.INI: Partition(1)   
 Partition   type : Primary    Visible        Bootrec-OEM-name: MSWIN4.1       
 Partition   size : 0x0001B708 =    54.9 MiB  =      6.996 cylinders           
FAT entry size of : 32  Bits   (FAT32   ) will be forced.                      
Size of FAT entry : 32  Bits    FAT label in Root : FAT32                      
FAT DIRTY status  : 0x01 = DIRTY, surface-SCAN/CHKDSK required (MS)            
FAT1 CRC-32 value : 0x9af8cdba  FAT2 CRC-32 value : 0x9af8cdba = OK            

chkdsk /f says:

The type of file system for the disk is FAT32.
The FAT32 file system program has been started.
FAT32: Unicode translate table for CP 850 loaded.
(UFAT32.DLL version 0.10a7 compiled on Oct 18 2016)
The volume label is FAT32.
The Volume Serial Number is 18E9-312B.
CHKDSK is checking fats :Ok.
CHKDSK is checking files and directories...
CHKDSK is searching for lost data.
CHKDSK has searched 100% of the disk.

    56642560 bytes total disk space.
           0 bytes in 0 hidden files.
        9216 bytes in 1 directories.
           0 bytes in extended attributes.
    39769088 bytes in 90 user files.
    16864256 bytes available on disk.

         512 bytes in each allocation unit.
      110630 total allocation units.
       32938 available allocation units on disk.

1% of the files and directories are fragmented.

locate says:

[c:\]locate UFAT32
c:/OS2/DLL/UFAT32.DLL

UFAT32.DLL says:

10-20-16  14:09         155,950    124  UFAT32.DLL

Signature:       @#Netlabs:0.10a7#@  "UFAT32 Helper DLL, Henk Kelder & Netlabs"
Vendor:          Netlabs
Revision:        0.10
File Version:    0.10
Description:     "UFAT32 Helper DLL, Henk Kelder & Netlabs"

FAT32.IFS says:

10-20-16  14:57         214,520    124  fat32.ifs

Signature:       @#Netlabs:0.10a7#@  "Fat32 Installable filesystem, Henk Kelder
& Netlabs"
Vendor:          Netlabs
Revision:        0.10
File Version:    0.10
Description:     "Fat32 Installable filesystem, Henk Kelder & Netlabs"

I get the same result from fat32chk.exe /f as I do from chkdsk /f (as I would expect).

What is necessary to reset the dirty flag, then? Am I missing something?

[erdmann]

You have the very same version that I am using.

Very strange. Can you redo with a medium that needs chkdsk and do a DFSee - chkdsk - DFSee sequence and compare "before" with "after" chkdsk ?

It surely works here. Maybe it depends in what way the medium is screwed up and what media it is exactly. I have tested it with "large floppy" sticks that needed a chkdsk. Maybe I have to redo with partitioned media ...

Lewis, can you try with "large floppy" media (take stick, completely remove all partitions, go to a windows box, format with FAT32 and then you have a "large floppy" stick).

[Lewis Rosenthal]

Okay, I can confirm that when there actually *are* corrections written to the media, the dirty bit is cleared (for partitioned media, at least).

The bigger problem (new ticket) is that we are not respecting the dirty flag and mounting the media anyway, instead of being sure to check it and then clear it.

Lars, just try setting the dirty bit on unpartitioned media and pulling the stick. This should leave it set. Reinsert, and run CHKDSK. Use DFSee to check if the flag is cleared. I will try this myself as soon as I can get to a Windows machine (hard to come by around here these days - LOL). I should be able to do it from Linux, though. I've done those before (created large floppy FAT32 media).

FWIW, DFSee will *not* clear the dirty flag during its check procedure, and this is (AFAIK) by design.

[Valery V. Sedletski]

2Lars: How did you managed to use the large floppy with FAT32 in OS/2? As far as I know, the large floppies in OS/2 need to be < 2gb and formatted with fat16, otherwise os2dasd will fail to mount it to FAT32 and mount the kernel FAT driver instead. It always mounts the kernel FAT on large floppies. Or, maybe, I missed some new os2dasd feature?

[erdmann]

See usbdrv210.zip on Hobbes. I have updated USBMSD.ADD to support "large floppies" that are formatted with FAT32. The limitations you mention (< 2GB, only FAT16) are long gone.
The trick was to "fake" an MBR (with a partition table) and a DLAT in memory and make OS/2 believe there is an additional track 0 (and some free space) preceding the real media. For OS/2 it is therefore seen as partitioned media.

[Valery V. Sedletski]

2Lars: Nice to know :) Will try the new drivers soon.

[erdmann]

Forgot to say: not only the MBR and DLAT sector are "faked" in memory but also the VBR (the first real sector on the large floppy, the one containing the real BPB).
Yes, "hidden sectors" is changed to "skip" all the sectors preceding the first real data sector (the original VBR).
Additionally, "NumHeads" and "SectorsPerTrack" are also changed to what OS/2 requires (NumHeads = 255, SectorsPerTrack = 63/127/255 depending on media size).
However, I don't think that booting will work from such a media as I suppose the BIOS will access the real VBR (because virtualization is not in effect on bootup). I have no clue what will happen if the values in the real VBR deviate from those emulated later on.
In short: I have never tried booting from USB media.

Another note: the number of hidden sectors is not necessarily 63. That's because of the necessity to align the "partition" to a cylinder boundary (OS/2 is very picky about that, it was such a pain in the butt). I decided to align the END of the partition to a cylinder boundary which means the START will not align if the partition is not an exact multiple of 255 (NumHeads) *63/127/255 (SectorsPerTrack) sectors.

[Lewis Rosenthal]

Per my comment:4, this was fixed and working for before the side discussion of large floppy support.

May we close this one, then?

[Valery V. Sedletski]

OK, closing this.