Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: FAT32
From: Alan Korr (post_at_pegasmail.com)
Date: 2002-04-03


Here you can find some details about fat.c for rockbox :

1) Rockbox only handles FAT32 partitions.

Due to the fact that harddisks used by JBP or JBR are higher than 5 GB, it is an absurdity to handle FAT12 or FAT16 partitions on those harddisks (the only exception is when splitting them in very small partitions - something to be avoided anyway).

By the way, it prevents us from space waste for code to handle FAT12 or FAT16 partitions.

2) Rockbox tries to use info from the backup BPB if the main BPB sector is invalid.

That way, we should be supposed to work with the last valid BPB, even if the main BPB sector were corrupted. Normally, we should never modify both the main BPB sector or the backup BPB sector, except for deactivating FAT mirroring when activated. At each boot, the backup BPB sector is copied into the main BPB sector if the latter is invalid and the former valid. BPB sectors are examined just while booting rockbox for determining available volumes, so we don't need to keep a copy of their sectors in memory.

 - read main BPB sector and check it;
 - if checking is unsuccessful, read backup sector and check it;
 - if checking is successful, write backup BPB sector in main BPB sector.

3) Rockbox never uses fat mirroring :

Rockbox should avoid writing sectors if not necessary. Fat mirroring would need to write a sector into each FAT (usually 2) and because they are not contiguous, that action would drain much more current from batteries to power harddisk. So we always deactivates FAT mirroring in both main BPB sector and backup BPB sector when FAT mirroring is activated. Checking and deactivating if necessary is only done while booting, i.e, while examining BPB sectors.

4) Rockbox avoids updating fsinfo sector :

If fsinfo is not used or has an unknown number of free clusters, there is no problem, for we ignore this sector.

If fsinfo is used and has an known number of free clusters, we set it unknown and write the fsinfo sector back into partition to prevent Windows from counting upon those fields for the next time it will access our partition.

The purpose is to avoid writing this sector back into the partition whenever we allocate or free a cluster chain.

Any question or request ?

/alan

_______________________________________________________________________
This mail was sent using http://www.pegasmail.com - Send Your Mail Now!



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa