[Info-mtools] Missing initialization of Case element?

[Ronny Nilsson]

Hi
I've had problems with mcopy creating invalid bitfilds for the special 
directorys ".." and "." in v4.0.18.


First I create an image:
        dd if=/dev/zero of=fat.img bs=512 count=30
        mformat -i fat.img -h 255 -s 63 -T 2104452 -F -v testing -M512 -S2
        mcopy -sQmvi fat.img /usr/include/X11/ ::


Then I check it with latest dosfstools v3.0.26:
$ fsck.vfat -nv fat.img
fsck.fat 3.0.26 (2014-03-07)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MTOO4018"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   1050624 bytes per FAT (= 2052 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 2117632 (sector 4136)
    262539 data clusters (1075359744 bytes)
63 sectors/track, 255 heads
         0 hidden sectors
   2104452 sectors total
/
  Bad short file name ().
  Auto-renaming it.
  Renamed to
/X11/DRI
  Has a large number of bad entries. (2/5)
  Not dropping it in auto-mode.
/X11/DRI/.
  Bad short file name (.).
  Auto-renaming it.
  Renamed to FSCK0000.000
/X11/DRI/..
  Bad short file name (..).
  Auto-renaming it.
  Renamed to FSCK0000.001
/X11/DRI/FSCK0000.000
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.
/X11/DRI/FSCK0000.001
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.
/X11/PM/.
  Bad short file name (.).
  Auto-renaming it.
  Renamed to FSCK0000.000
/X11/PM/..
  Bad short file name (..).
  Auto-renaming it.
  Renamed to FSCK0000.001
/X11/PM/FSCK0000.000
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.
/X11/PM/FSCK0000.001
  Contains a free cluster (3). Assuming EOF.
/X11/extensions/.
  Bad short file name (.).
  Auto-renaming it.
  Renamed to FSCK0000.000
/X11/extensions/..
  Bad short file name (..).
  Auto-renaming it.
  Renamed to FSCK0000.001
/X11/extensions/FSCK0000.000
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.
/X11/extensions/FSCK0000.001
  Contains a free cluster (3). Assuming EOF.
/X11/FONTS/.
  Bad short file name (.).
  Auto-renaming it.
  Renamed to FSCK0000.000
/X11/FONTS/..
  Bad short file name (..).
  Auto-renaming it.
  Renamed to FSCK0000.001
/X11/FONTS/FSCK0000.000
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.
/X11/FONTS/FSCK0000.001
  Contains a free cluster (3). Assuming EOF.
Checking for unused clusters.
Checking free cluster summary.
Leaving filesystem unchanged.
fat.img: 167 files, 426/262539 clusters



Despite prior dosfstools versions doesn't complain I don't think it's a 
regression in dosfstools. Because if I add a simple
        memset(entry, 0, sizeof(direntry_t))
first thing in direntry.c:initializeDirentry() the problem goes away:
$ fsck.vfat -nv fat.img
fsck.fat 3.0.26 (2014-03-07)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MTOO4018"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   1050624 bytes per FAT (= 2052 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 2117632 (sector 4136)
    262539 data clusters (1075359744 bytes)
63 sectors/track, 255 heads
         0 hidden sectors
   2104452 sectors total
/
  Bad short file name ().
  Auto-renaming it.
  Renamed to
Checking for unused clusters.
Checking free cluster summary.
fat.img: 167 files, 426/262539 clusters



Inspecting the binary FAT image I've been able to track the fault down 
to "Case" in "struct directory". It's a bitfield where only two bits seems to 
be in use(?). Without my patch the bitfield can end up with suspicious data 
but when initialized with memset() it works.

The remaining error reported by fsck.vfat above is a known issue in 
dosfstools:
https://bugzilla.redhat.com/show_bug.cgi?id=1078057


/Ronny Nilsson

initialize-direntry.patch
Description: Text Data