Page 1 of 2
fat32 only partially working
Posted: Sat Apr 21, 2007 12:26 am
by supagu
i've formatted my drive to fat32 as i try to put together a FAT32 file reader for my OS.
Problem is something are giving me suspect values.
Code: Select all
struct BootRecord
{
unsigned char jumpCode[3];
char OEMName[8];
unsigned short bytesPerSector;
unsigned char sectorsPerCluster;
unsigned short reservedSectors;
unsigned char numberOfCopiesOfFAT;
unsigned short maxRootDirEntries;
unsigned short totalSectors16;
unsigned char mediaDescriptor;
unsigned short sectorsPerFAT16;
unsigned short sectorsPerTrack;
unsigned short numHeads;
unsigned long hiddenSectors;
unsigned long totalSectors32;
unsigned long sectorsPerFAT32;
unsigned short flags;
unsigned char majorVersion;
unsigned char minorVersion;
unsigned long rootDirCluster;
unsigned short FSInfoSectorNum;
unsigned short backupBootSectorNum;
unsigned char reserved[12];
unsigned char logicalDriveNumOfPartition;
unsigned char unused;
unsigned char extendedSignature;
unsigned long serialNum;
char volumeLabel[11];
char FATName[8];
unsigned char executableCode[420];
unsigned short bootRecordSignature;
} __attribute__((packed));
here is my strucuture to read the first sector of the partition.
i've dumped out some key values, some of which are good, some are just bad
partition #0 at sector 63
OEMName: MSWIN4.0
FATName: "~
Volume Label: x
Sectors per cluster: 16
reserved sectors: 8
copies of fat: 2
num sectors per fat16: 256
num sectors per fat32: 1026097280
FIS Info at sector: 8224 (at sector 8224 + 63, its just null!!!)
:-/
ideas of what i should try?
Posted: Sat Apr 21, 2007 2:42 am
by mystran
Your "sectors per fat32" comes out as 0x3D290080, which is stored (in little endian) as 80 00 29 3D. Now 80 is first hard disk (AFAIK) and 28/29 are the possible valid signatures for FAT16.
So I'd say: congratulations, you have a FAT16 partition.
Posted: Sat Apr 21, 2007 2:49 am
by mystran
You could check maximum number of root directory entries to detect whether something is FAT12/16 or FAT32, to know how to interpret the extended block.
Then if it's FAT12/16, you can read the FAT12/16 version of the extended block to see which one.
Oh, and I'd suggest handling all three in the same driver, since the only differences are root directory (FAT12/16 special case, FAT32 doesn't) and size of FAT entries (easily solved by a switch or three functions to call with a pointer).
edit: oh and one has to mask out (or not read) the upper 2 bytes of cluster indexes for FAT12/16 as those are used for EA-index so they might not be zero, but in any case the differences are minor
Posted: Sat Apr 21, 2007 3:50 am
by pcmattman
I have a FAT32 driver (without long filename support) in my CVS repositry (file io). You could look at that (it works) and see what's wrong with your code.
Posted: Sat Apr 21, 2007 11:54 am
by supagu
yeah this seems to be an indian issue, for example, dumping out the root cluster number normally i get something crazy huge, but if i swap the bytes around i get something more sensible:
17747
Posted: Sat Apr 21, 2007 2:15 pm
by Brynet-Inc
supagu wrote:yeah this seems to be an indian issue, for example, dumping out the root cluster number normally i get something crazy huge, but if i swap the bytes around i get something more sensible:
17747
LOL Indian issue? good grief.. It's Endian..
I look at my keyboard and notice the "E" and "I" keys are considerably far apart..
Posted: Sat Apr 21, 2007 7:09 pm
by supagu
ahah yeah well it was 4am when i wrote that
Posted: Sat Apr 21, 2007 7:52 pm
by supagu
okay it was fat16 even though some of my tools said it was fat32, so im using naother format tool
Posted: Sat Apr 21, 2007 10:06 pm
by B.E
From memory (havn't read the offical documentation for over 2 years), isn't the FAT type determined by the number of clusters on the disk?
Posted: Sun Apr 22, 2007 3:44 am
by supagu
pcmattman, I've been looking at your fat driver, as im now stuck trying to work out how to iterate over my files.
so i've got my root directory sector (98) and the offset is 12.
This my first dword is my fat entry which indicates its only a single cluster in length (first DWORD points to the next file cluster right?).
So now I assume i have to iterate over each dword in the cluster to find other clusters? do i check each linked cluster the first DWORD is next file cluster as mentioned but where are the Directory table sturctures? they certainly arent in the root directory cluster :-/
Posted: Sun Apr 22, 2007 3:47 am
by pcmattman
Iterate as in read in more than one cluster?
In the FAT, which you should know how to access, each entry points to the offset in the FAT of the next entry. They also, when the first data sector is added to the value, point to the real sector in which the next sector of data lies.
When you reach the EOF indicator (usually 0xFF(bit length)) you know that you can't read the file anymore.
I forgot to put in the iterative facility into my FAT16/32 driver... But it is in the FAT12 one.
Posted: Sun Apr 22, 2007 4:16 am
by supagu
well im confused what to do with the root cluster.
Is not the first DWORD of each cluster the cluster number of the next cluster in the files linked list?
but does the root cluster (after this first linked list DWORD) contain a list of DWORD's to other clusters or does it contain an array of directroy table structures, ie store the file name, and attributes etc...?
Posted: Sun Apr 22, 2007 3:24 pm
by pcmattman
The root cluster is effectively the root directory. The cluster entry in the FAT for the root directory is the same as any other entry.
Reading the root directory is easy, you just go through the sector 32 bytes at a time (same for any directory).
Posted: Sun Apr 22, 2007 4:01 pm
by mystran
In FAT12 and FAT16 the root directory is a special case, and is always at the beginning of the data area. In FAT32 the root directory is just like any other directory, and it's location can be found in the EBPB.
Posted: Mon Apr 23, 2007 4:53 am
by supagu
pcmattman wrote:The root cluster is effectively the root directory. The cluster entry in the FAT for the root directory is the same as any other entry.
Reading the root directory is easy, you just go through the sector 32 bytes at a time (same for any directory).
so this 32bytes is "Storage Organization" from this page:
http://home.teleport.com/~brainy/lfn.htm
which would imply there are string some where in my root cluster, which there isnt
red arrow points to offset 12, sector 98. This is the start of my root cluster