File System

XTAF

The file system is derived from the age-old MS-DOS file system and can be considered as a cleaned-up version of it.

Note that, while not part of the file system itself, the media which contain this file system do not have a master file table which describes which file system starts where. It is up to the consumer (Xbox360, geom_xbox360 kernel module, ...) to know this.

The file system is divided into 4 parts:

• the header (the BOOT sector on FAT file systems)
• the file allocation table
• the ROOT directory cluster
• the rest of the file system (both directories and files)

All multi-byte values contained in each part are [1] big-endian.

An example implementation in C is available as uxtaf.c (18156 bytes, MD5 = 8bf05607ab921b2c68d58c987e8177fd) and is accompanied by a small text (998 bytes, MD5 = de783817d847402d0c88a13663ff9d0d).

The header

The header is 1 sector (512 bytes) long and contains :

Offset	Length	Content	Description
0x000	4	XTAF	Magic identifier
0x004	4		Serial number of the file system, could also be 0 or -1
0x008	4		Number of sectors per cluster
0x00C	4	1	Number of copies of the file allocation table
0x010	2	0	Unknown
0x012	0xFEE	0xFF	Unused / unknown

The file allocation table

This table is equivalent to its ancestor in the FAT file system, except that all values are big-endian.

The first two entries are possibly slightly different:

• Entry 0 contains a copy of the media descriptor (0xF8, hard disk), but the clean/ok bits might not be used. Note that on the cache partition, the value seems to be reversed: 0xFFF8 instead of 0xF8FF
• Entry 1 is always set to 16 or 32 1-bits.

The size of the FAT (in bytes) is calculated as

uint64_t file_system_size;
uint32_t spc; /* sectors per cluster */
uint32_t numclusters = file_system_size / (512 * spc);
uint8_t fatmult = numclusters >= 0xfff4 ? 4 : 2;
uint32_t fatsize = numclusters * fatmult;
if (fatsize % 4096 != 0)
        fatsize = ((fatsize / 4096   1) * 4096; /* round up if not multiple of 4 kB */

The cache and the compatibility partition have a 4096-byte hole of 0-bytes right after the FAT.

The above algorithm already shows that the file system is 32-bits if the number of clusters is at least 0xFFF4, and 16 bits otherwise. It seems likely that bits 28-31 are unused on 32-bits file systems.

The ROOT directory cluster

The root directory is located right after the FAT and the possible 4096-byte hole. This cluster is not covered by the FAT.

The size of the root directory is 1 cluster. Its syntax and semantics are the same as that of normal directories.

Also of note is that the ROOT cluster is numbered "cluster 1", not cluster 0. This means that the next cluster, the first data cluster, is referred to as "cluster 2" in the FAT entries.

The actual data

The actual data is located after the root directory cluster (i.e. cluster 2). Cluster 2 is the first entry covered by the FAT.

Files

The file contents is stored per cluster as indicated by the FAT and the starting cluster (see below). If the file is larger than one cluster, it is stored in multiple clusters. If the length of the file is not a multiple of the cluster size, then the last cluster is only partially used.

Directories

Directories are stored in a tabular format. Because directories are normal files with the "directory" bit set, they are allocated in the FAT and may therefore cover multiple clusters. This makes it possible to have many files in one directory.

Each entry of the directory table is 64 bytes long.

An entry can be set to all 0xFF bytes, which means that this entry is unused and probably marks the end of the directory contents. Used entries are filled as follows:

Offset	Size	Description
0x00	1	length of the file name, or 0xE5 for deleted files
0x01	1	file flags
0x02	0x2A	file name, padded with either 0x00 or 0xFF bytes
0x2C	4	starting cluster of file, 0 for empty files
0x30	4	file size, 0 for directories
0x34	2	creation date
0x36	2	creation time
0x38	2	access date
0x3A	2	access time
0x3C	2	update date
0x3E	2	update time

The file flags and the date and time fields are in the same format as the one used in the FAT file system.

The order of the creation/access/update stamps is not completely certain, but empirical evidence shows that the above order is the most likely one.

The volume bit is unused, the volume label is instead stored in a file "name.txt" in the root directory. The contents of this file is big-endian UTF16 (I guess), for example "ren� hd" is stored as:

0xFE 0xFF 0x00 0x65 0x00 0x6E 0x00 0xE9 0x00 0x20 0x00 0x68 0x00 0x64

The following characters are found in XTAF file names from actual disk images:

• 0x20, 0x24, 0x2e ( SPACE $ . )
• 0x30-0x39 (digits 0-9)
• 0x41-0x5a (letters A-Z)
• 0x5f ( _ )
• 0x61-0x7a (letters a-z)

Unlike the FAT file system, XTAF has no . and .. entries in the directory tables. This means that it is only possible to go to the parent directory by remembering its cluster number.