Creative Zen X-Fi
Overview
This page describes the "minifs" file system used in many Creative devices. All this information has been obtained by reverse engineering and could contain errors.
Introduction
This file system is typically used to store system files and can be updated by upgrading the device (the upgrade being an encrypted archive, it can actually contain any file).
It is suspected that there are two versions of it, and only two sizes have been observed: 20MiB and 50MiB.
Version |
Devices |
1 |
Zen Vision: M |
2 |
ZEN X-Fi, Mozaic |
Version 2
High-Level View
The file system is organised as follows:
Offset (blocks) |
Size (blocks) |
Name |
Comment |
0 |
1 |
Super Block |
|
1 |
1 |
? |
Unknown use |
2 |
? |
Chain |
One chain per file, a chain typically takes one block |
? |
1 |
Chain Bitmap |
|
? |
1 |
File List |
|
? |
1 |
Data Bitmap |
|
? |
? |
Data |
|
Super Block
The super block is located in first sector of the first block (block address 0) and contains some very important information on the file system.
Offset |
Size |
Name |
Value |
Comment |
0 |
4 |
Version |
2 |
Always 2 for version 2 |
4 |
4 |
Block Size |
16384 |
Number of bytes per block, always 16384 in practice |
8 |
4 |
Max File Size |
40894464 |
Maximum size of a file (bytes) |
12 |
2 |
Nr entries |
64 |
Maximum number of files |
14 |
2 |
? |
1 |
If true, chains are block-aligned, otherwise not |
Although the super block gives some flexibility on the layout on the system, Creative's code make a number of assumption:
- block size must be 0x4000
- all directory entries fit into one block
- data bitmap fits into one block
- each chain fits into one block
Also note that block addresses in the chains are stored on a 16-bit integer, thus limiting the total number of blocks to 65536.
Unknown block
The second block (block address 0) of the system has unknown used. It is apparently untouched by Creative's code.
Chains
Starting from the third block (block address 2), follows as many chains as the maximum number of files. The fields of a chain are described below. A chain does not necessarily takes a whole block. The behaviour depends on the last field of the super block: if set to true, then each chain is rounded up to take an integer count of blocks. Otherwise, they can cross block boundaries.
Offset |
Size |
Name |
Value |
Comment |
0 |
4 |
Unknown |
0 |
Unknown use |
4 |
4 |
Length |
? |
Number of blocks in the chain |
8 |
2 x N |
Blocks |
? |
List of used blocks, each block address is 16-bit large. The list is always terminated by an extra 0xffff entry |
It should be noted that there is some redundancy: the length field gives the number of blocks and the list is 0xffff terminated. Creative's code relies on the presence of this 0xffff which seems mandatory although it is unclear what happen when a files uses exactly all blocks of the chain !
The chain size is given by
8 + 2 * max_nr_blocks_per_file
where
max_nr_blocks_per_file
is given by
Max File Size / Block Size
. Depending on the last field of the super block, this quantity is rounded up to block size.
Chain Bitmap
The chain bitmap describes the empty/used chains. Each bit describe the state of a chain: 1 for used and 0 for free. Chain 0 corresponds to least significant bit of the first byte, and so on.
--
AmauryPouly - 02 Jun 2013
Copyright © by the contributing authors.