XTAF: Difference between revisions

From Xenon Wiki
Jump to navigation Jump to search
imported>Bertl
m (moved here from wrong page)
 
imported>CLK
(removed everything, redirecting to FATX)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= <span class="mw-headline"> The Xbox360 file system, also known as XTAF. </span> =
#REDIRECT [[FATX]]
 
The file system is derived from the age-old [http://en.wikipedia.org/wiki/File_Allocation_Table 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, [http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107707 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 [http://en.wikipedia.org/wiki/Endianness [1]] big-endian.
 
An example implementation in C is available as [ftp://rene-ladan.nl/pub/distfiles/uxtaf.c uxtaf.c] (18156 bytes, MD5 = 8bf05607ab921b2c68d58c987e8177fd) and is accompanied by [ftp://rene-ladan.nl/pub/distfiles/uxtaf.txt a small text] (998 bytes, MD5 = de783817d847402d0c88a13663ff9d0d).
 
== <span class="mw-headline"> The header </span> ==
 
The header is 1 sector (512 bytes) long and contains :
 
{| border="1"
! 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
|}
 
== <span class="mw-headline"> The file allocation table </span> ==
 
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 &gt;= 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.
 
== <span class="mw-headline"> The ROOT directory cluster </span> ==
 
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.
 
== <span class="mw-headline"> The actual data </span> ==
 
The actual data is located after the root directory cluster (i.e. cluster 2). Cluster 2 is the first entry covered by the FAT.
 
=== <span class="mw-headline"> Files </span> ===
 
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.
 
=== <span class="mw-headline"> Directories </span> ===
 
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:
 
{| border="1"
! 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.

Latest revision as of 07:11, 7 September 2011

Redirect to:

Retrieved from "https://www.xenonwiki.com/index.php?title=XTAF&oldid=5175"