0

I was experimenting around with filesystems in linux. I want to understand a few issues. Here are the commands that I have used:

truncate disk.img -s 1M
mkfs.vfat -F12 -S512 -s1 disk.img 
#I have made a FAT12 filesystem on a simple 1 MB file in my home directory

Now I can mount my file with:

sudo mount disk.img /mnt

Why do we use sudo here?? I cannot mount without sudo

Now I copy a file spanning 2 clusters to the mountpoint:

sudo cp file.bin /mnt 

Then I umount the disk:

sudo umount /mnt

I use a hex editor like ghex to view what exactly has happened after all this:

ghex disk.img

In the FAT, I see the following (RAW format):

(Beginning from byte 0x200, after the bootsector)
f8ff ff00 4000 ff0f 0000 0000 ..........

Here's my main question: I thought that FAT12 used 1.5 bytes per cluster in the FAT, but it seems to be using 2? (I'm not sure about this, maybe I don't understand FAT12 that well)

1 Answers1

3

I thought that FAT12 used 1.5 bytes per cluster in the FAT, but it seems to be using 2

1.5 indeed. Your doubts may be because in your example the cluster #2 is free; this may be a surprise to you.

Relevant fragments of The FAT filesystem by Andries Brouwer:

The first cluster of the data area is cluster #2. That leaves the first two entries of the FAT unused. In the first byte of the first entry a copy of the media descriptor is stored. The remaining bits of this entry are 1. In the second entry the end-of-file marker is stored. […]

Two FAT12 entries are stored into three bytes; if these bytes are uv,wx,yz then the entries are xuv and yzw.

Possible values for a FAT12 entry are: 000: free, 002-fef: cluster in use; the value given is the number of the next cluster in the file, ff0-ff6: reserved, ff7: bad cluster, ff8-fff: cluster in use, the last one in this file. […]

Let's decode then.

f8ff ff00 4000 ff0f 0000 0000
f8ff ff                        - entries 0,1
       00 4000                 - entries 2,3
       uv wxyz                   and the sequence according to the citation
               ff0f 00         - entries 4,5
               uvwx yz
                      00 0000  - entries 6,7

uv,wx,yz → xuv, yzw:

00 40 00 -> 000 004
ff 0f 00 -> fff 000

This gives us the following:

  1. 000 – free
  2. 004 – cluster in use; the next cluster is #4
  3. fff - cluster in use, the last one in this file
  4. 000 - free

Check the directory entry for the file in question (I expect it at the offset 1a00).

Bytes   Content
0-10     File name (8 bytes) with extension (3 bytes)
[…]
26-27   Starting cluster (0 for an empty file)
[…]

Bytes 26-27 should hold 0300 in your case. It's little-endian, the human-readable (big-endian) value is 0003. The starting cluster is #3.

The file starts at cluster #3, the next cluster is #4 and it's the last cluster in this file. The file spans two clusters. Everything fits.