FAT File System

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Directory Entry File Size Field:
Offset: 0x1C-0x1F
Type:   uint32_t (4 bytes, unsigned)
Range:  0 to 4,294,967,295 bytes
 
Maximum file size = 2³² - 1 = 4,294,967,295 bytes
                          = 4 GB - 1 byte
                          ≈ 3.99999999906... GB
 
Impact Examples:
- DVD ISO image:       4.7 GB  → ❌ Cannot store
- Blu-ray ISO:         25 GB   → ❌ Cannot store
- Large video files:   Often >4GB → ❌ Cannot store
- Database files:      Often >4GB → ❌ Cannot store
- Virtual machine disks: Often >4GB → ❌ Cannot store
 
Workarounds:
- Split large files (e.g., .001, .002 archives)
- Use exFAT (64-bit file size field)
- Use NTFS, ext4, or other modern file system

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

FAT Directory Entry Attributes:
- Read-only  (can be changed by any user with disk access)
- Hidden     (cosmetic only, easily bypassed)
- System     (cosmetic only)
- Archive    (backup flag, no security implications)
 
NTFS Security Descriptor (per file):
- Owner SID (who owns the file)
- Primary Group SID
- Discretionary ACL (DACL):
  - Allow/Deny entries for:
    - Specific users (by SID)
    - Specific groups
    - Permissions: Read, Write, Execute, Delete, 
      Change Permissions, Take Ownership, etc.
- System ACL (SACL):
  - Audit rules for access logging
 
Example NTFS ACL:
  Owner: DOMAINJohnDoe
  Allow: DOMAINAdmins - Full Control
  Allow: DOMAINDevTeam - Read, Execute
  Deny:  Guest - All Access
  Audit: Everyone - Delete (Success/Failure)
 
FAT equivalent: None. Everyone has full access.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Creating a new file on FAT requires multiple disk writes:
 
Step 1: Find free clusters in FAT
Step 2: Mark clusters as allocated in FAT (write FAT)
Step 3: Write file data to clusters
Step 4: Create directory entry (write directory)
Step 5: Update FAT backup copy (write second FAT)
 
What if power fails at each step?
 
After Step 1: No damage - FAT unchanged
After Step 2: LOST CLUSTERS - FAT says "in use" but no file references them
After Step 3: LOST CLUSTERS + orphaned data
After Step 4: File exists, data written, but FAT backup out of sync
After Step 5: Success
 
The most common corruption: Lost clusters (cross-link also possible)
Recovery requires CHKDSK/SCANDISK to scan entire FAT and directory tree

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// Common FAT corruption types and their causes
 
// 1. Lost Clusters (most common)
// FAT entries marked as "in use" but no directory entry references them
// Cause: Power loss after FAT update but before directory update
// Detection: Compare FAT to all directory entries
// Fix: Mark as free or save to file (SCANDISK creates FILE0001.CHK)
 
// 2. Cross-linked Files
// Two directory entries claim the same cluster
// Cause: Power loss during file move/copy, or FAT cache inconsistency
// Detection: Build cluster-to-file map, find duplicates
// Fix: Clone the cluster for one file, truncate the other
 
// 3. Invalid File Sizes
// Directory entry size doesn't match cluster chain length
// Cause: Power loss during file truncation/extension
// Detection: Walk cluster chain, calculate actual size
// Fix: Adjust file size or truncate chain
 
// 4. Circular Cluster Chains
// Cluster chain loops back to earlier cluster
// Cause: FAT corruption
// Detection: Floyd's cycle detection during chain walk
// Fix: Break the cycle with end-of-chain marker
 
// 5. FAT/FAT2 Mismatch
// Primary and backup FAT copies differ
// Cause: Power loss during FAT update
// Detection: Compare both FAT tables
// Fix: Copy the "good" FAT to the other (heuristics determine which)
 
// CHKDSK does all of this, but requires O(n) time
// On a 1TB FAT32 volume with millions of files, this can take hours

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

TIMESTAMP ISSUES:
 
1. Two-Second Resolution
   - Time field has 5 bits for seconds/2
   - Cannot represent odd seconds (13:44:21 stored as 13:44:20)
   - Creation time has 10ms resolution via separate field
 
2. Access Date Only (No Time)
   - accessDate field: 16 bits for date
   - No corresponding time field
   - Cannot record access by hour/minute
 
3. No Change Time (ctime)
   - Unix: mtime (data changed), ctime (metadata changed)
   - FAT: Only mtime, no way to track permission/name changes
   - (Not applicable since FAT lacks permissions anyway)
 
4. Year 2107 Problem
   - Year stored as offset from 1980 (7 bits: 0-127)
   - Maximum year: 1980 + 127 = 2107
   - Archival storage may face issues
 
HARD LINK IMPOSSIBILITY:
 
In Unix/NTFS: Multiple directory entries can point to same inode/MFT record
- File data stored once, multiple names
- Reference count tracks links
- Delete one name, file persists if other links exist
 
In FAT: Each directory entry contains:
- First cluster number (file start)
- File size
- Timestamps
 
Creating "hard link" would mean two entries with same first cluster
- BUT: Each has independent size, timestamps
- No reference counting
- Deleting either entry frees the clusters, breaking the other
- FAT has NO concept of inode or file identity separate from name

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

FAT Directory Structure: Linear list of 32-byte entries
 
To find "document.txt" in a directory with 10,000 files:
- Worst case: Scan all 10,000 entries
- Average case: Scan 5,000 entries
- Time complexity: O(n)
 
Each 32-byte entry requires:
- Reading from disk (or cache)
- Comparing filename (11 bytes for short, up to 255 for LFN)
 
With LFN: Each file may use 1-21 entries
- 10,000 files with average 2 LFN entries each = 30,000 entries
- At 32 bytes each = 960 KB of directory data to scan
 
Compare to NTFS B+tree directory index:
- B+tree enables O(log n) lookup
- 10,000 files: ~14 comparisons maximum
- 1,000,000 files: ~20 comparisons maximum
 
For small directories (< 100 files): Negligible difference
For large directories (> 10,000 files): FAT noticeably slower

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

FAT Data Path:
App writes data → OS caches → FAT updates FAT table → Data written
                                                    ↓
                              NO verification that write succeeded
                              NO verification that read returns what was written
                              NO detection of silent data corruption (bit rot)
 
ZFS Data Path:
App writes data → ZFS calculates checksum → Data + checksum written
                                          ↓
On read: ZFS calculates checksum, compares to stored
         If mismatch: Retrieve from mirror/parity, correct primary
         Error reported only if uncorrectable
 
Corruption Detection Rate:
- FAT: ~0% (no detection mechanism)
- NTFS: Partial (some metadata checksums since Windows 8)
- ext4: Partial (optional checksums for metadata)
- ZFS/btrfs: 100% (checksums on all data and metadata)
 
For archival storage, FAT provides NO assurance that data
retrieved matches data written (beyond disk hardware ECC).