See also: Mapping DOS FAT to MDFAT for info on interpreting the MDFAT.

The MDFAT contains one 32-bit entry for each FAT cluster.  Each entry
describes the location in the Sector Heap of the start of the cluster, how
many sequential sectors are actually occupied, and whether the data is
compressed or raw.

The MDFAT region starts one sector after the end of the BitFAT; its
location can be calculated as MdBpbRec.wMdFatStart+1 sectors from the
start of the CVF.  It may be as large as 512 sectors (256K=262,144 bytes).

Each 32-bit entry is formatted as follows:

3 3 2 2 2 2 2 2 2 2 2 2 \\
 1 0 9 8 7 6 5 4 3 2 1 0 // 1 0 
 u r sizRaw  sizCmpr 0 location 
                         //       bits      mask
                                 0-20: 001fffffH location of the first
                                                 sector (NOT an offset from
                                                 Sector Heap; see below)
                                   21: 00200000H reserved for future use
                                22-25: 03c00000H size (sectors) as stored
                                26-29: 3c000000H size when uncompressed
                                   30: 40000000H 1 = uncompressed (raw)
                                   31: 80000000H 1 = entry is in use

location (bits 0-20; 21 bits) This identifies the location of the first of
one or more contiguous sectors in the Sector Heap that contain
the data represented by FAT entry that corresponds to this
MDFAT entry.

Add 1 to this number to get the sector offset from the start
of the CVF.

A 21-bit number can be as large as 2,097,152, so an MDFAT is able
to describe 33,554,432 (2M * 16) sectors or a 16 GB disk
(although DoubleSpace supports only up to a maximum of 512 MB).

The up-to-16 CVF sectors that contain one "compressed cluster" of
data are always contiguous.

res (bit 21; 1 bit) this bit is always cleared to 0.  It is reserved
for future use.

sizCmpr (bits 22-25; 4 bits) this is the number (-1) of sectors used to
contain the cluster's data; i.e., 0000=1, 0001=2, 0010=3, ...

It is possible for this to be larger than sizRaw, but only when
sizRaw is less than 15.

sizRaw (bits 26-29; 4 bits) this is the size (-1) of the data when it is
uncompressed; i.e., 0000=1, 0001=2, 0010=3, ... 1111=16.

For an uncompressed cluster (isUncmpr=1), the content of this
field is undefined.

isUncmpr (bit 30; 1 bit) This flag indicates whether or not the data for
this cluster is stored in compressed form.

1 indicates uncompressed (raw); 0 indicates compressed.

DoubleSpace will store a cluster in uncompressed format if it
finds that the compression algorithm cannot save at least one
sector in a given cluster (for instance, when storing pre-
compressed .ZIP files).

isUsed (bit 31; 1 bit) This flag indicates whether or not this
MdFatEntryRec is currently in use (see notes, below).

1 indicates used; 0 indicates unused.

Notes:   To locate a file's compressed data sectors: Obtain the file's
starting cluster number from the directory entry and, using
standard File Allocation Table-chain tracing, determine what
clusters it occupies.  Add MdBpbRec.wFirstData to a DOS FAT
cluster number and use the sum as an index into the MDFAT.

See Mapping DOS FAT to MDFAT for illustrated details.

  To decompress a cluster:  Seek to the first sector of the
cluster in the Sector Heap and read sizCmpr sectors into a
local buffer.  Use MRCI Fn 0002H to decompress the data.

  A compressed cluster begins with 'MD00' (4dH,44H,00H,00H) or
'MD0 ' (4dH,44H,00H,01H) or 'MD0 ' (4dH,44H,00H,02H).  But use
the isUncmpr field to see if it is compressed.  See Sector Heap
for related info.

  The isUsed flag helps DoubleSpace support FAT-based undelete
programs.  When sector of the FAT is written to disk,
DoubleSpace compares the old FAT to the changed FAT and checks
the isUsed flag of the corresponding entry in the MDFAT.  It
can infer one of the following operations:

DOS allocated a cluster:
isUsed=0 and FAT entry went from 0 to any

DOS or utility freed a cluster (e.g., a DS-unaware defragger):
isUsed=1 and FAT entry went from any to 0

Utility resurrected a cluster (e.g., undelete):
isUsed=0 and FAT entry went from 0 to any

Bookkeeping integrity lost (should never happen):
isUsed=1 and FAT entry went from 0 to any

  Each time DoubleSpace mounts a volume, it rebuilds the BitFAT
based on the contents of the MDFAT.

  An entry containing 00000000H: It is possible for an
MdFatEntryRec to contain only zeros.  This can occur when you
open a file, and seek at least 8K past the end of the last
cluster in the file, then write at least one byte.

In this case, DoubleSpace considers the cluster to be
"infinitely compressible."  The 8K of disk space represented by
the corresponding FAT entry takes no sectors in the heap.  If
you find the need to "decompress" the data represented by such
an entry, just return a full cluster of 0s.

Interestingly, if you use Copy (or other command) to duplicate
a file with such a cluster, the resulting physical length will
be larger--the duplicated cluster of 0s will occupy one
physical sector.

- -