dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Search | Go
Wiki > Main > CreativeMiniFS

Creative Zen X-Fi


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.


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.


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

r6 - 02 Apr 2021 - 20:46:06 - UnknownUser

Copyright © by the contributing authors.