fat32 only partially working

[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?

[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.

[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

[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.

[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

[Brynet-Inc]

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..

[supagu]

ahah yeah well it was 4am when i wrote that

[supagu]

okay it was fat16 even though some of my tools said it was fat32, so im using naother format tool

[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?

[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 :-/

[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.

[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...?

[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).

[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.

[supagu]

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