I tested the latest version 0.91 of chkdsk at
http://users.telenet.be/imre/FreeDOS/ chkdsk c: works, but chkdsk a: (from
diskette) gives an error message.

I have sent at least two mails to Imre Leber, but got no response.

defrag 1.22 has some bugs too (I forgot the exact text) but I have also sent
them to Imre Leber. If you need them once again, I will look for them.
One of the bugs was that it did not work on a 400 GB HD (serial ATA, FreeDOS
worked on it).

Fritz gets the error "Assertion failed: size, file bitfield.c, line 34".
This means that something tried to allocate a zero-sized bitfield.

This could happen at various places:

- CompressFastTreeMap / ConvertTreeMaps, if population count is 0

- IntelligentWalkDirectoryTree, if fat size is 0?
  It seems unlikely that the fat size can be 0 at this point.

- maybe other attempts to process things with cluster number 0?
  IsLabelValid should probably trap the value 0...

- WriteFatLabel (edit a cluster chain) might create a zero size
  bit field if the FAT size is a multiple of 64k sectors, which
  only happens for FAT32 with N*8 Mio clusters (at least 4 GB)

It would probably be good if UpdateHandleStruct could check
for cases like "0 sectors per FAT" early... On the other hand,
main() could give better DescriptorCheck feedback...

Best candidates for the bug are probably the "0 population
count" and "boot sector plausibility checks too weak" issues.

Eric

I discussed this problem with Fritz in 8/2008 and
after some experimentation we found out that not
checking A: is the problem... Chkdsk fails because
the test diskette of Fritz has no subdirectories
on it. This is a bug in handling of empty TreeMaps.

I believe the problem is in ConvertTreeMaps when
newlen stay 0 when collecting all subdirectories?
After all, the error message MEANS that something
tried to create a zero sized bit field. On the
other hand,  CompressFastTreeMap  may also need
modifications to deal with no field or an empty
field being returned by  ConvertTreeMaps  then?

Or would that be no problem here? It seems that we
can handle a NULL FastTreeMap already anyway ;-)

Thanks for fixing in any case :-)

Changing summary from:

chkdsk a: does not work

to:

chkdsk fails (treemap...) if no subdirectories