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)

Suraaj K S
  • 123
  • The question about sudo is a different issue. Mounting affects the whole OS, it deals with the kernel, the result is seen by all users. Such "global" actions normally require root access. The root may provide tools to mount FUSE. Any FUSE is operated by a userspace program, so it's not "global". For FAT it's fusefat (at least in Debian, fusefat disk.img ~/mnt/ -o rw+ to mount, fuser -u ~/mnt/ to unmount). Please see this. – Kamil Maciorowski Dec 27 '19 at 11:01

1 Answers1

2

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.

Kamil Maciorowski
  • 74,068