In my last installment Recovering FAT 32 With File System Markers, I offered a brief outline of a case that destroyed a FAT32 file systems major components. This was done by formatting the drive using an operating system that is not native to the file system. In other words, a Mac was used to format the drive when the original formatting used was Microsoft. In addition I concluded that a way to recover the data on the drive was to use the file entry record that is created for each file, and folder, in the fil system. In this article I will explain the on-disk format of the file entry record and some of the mechanics used to relate clusters.
Since a small program will be offered at the end of this sequence of articles the on-disk explanation will use ‘C’ notation and a defined record data type using structures. The following is the structure I use in my software to denote a file entry record.
#define SZ_FILE_ENTRY sizeof(FILE_ENTRY)
#define FILE_ENTRY_NULL (PFILE_ENTRY)0
This file entry record format has been in use since the inception of DOS FAT File System. There may have been some fields that were at one time referred to as reserved but the size and basic design of the record has always remained the same. The following is a description of the fields used to recover the original folder heierarchy.
1. FE_Name — This is from the old 8.3 notation and the first eight characters of the file name. In later articles I will cover the long file name logic and how we can use that to enhance our search routines. It is important to note that if the file name is less than eight characters the rest of the name is space filled (0x20)
2. FE_Extension — The second part of the 8.3 notation that has the same rule set as the FE_Name field. When displayed the data in this field is after the period ‘,’.
3. FE_StartClusterHI — Stored here is the binary high short value of the starting cluster of the file, and or folder.
4. FE_StartClusterLO — Stored here is the binary low short value of the starting cluster of the file, and or folder
5. FE_FileSize — Lastly the file size. If this file entry record defines a folder then this value is zero (0x00). In addition you can see that the file size is an unsigned int, so the largest file size that can be stored is 4,294,967,295 bytes, or 4GB.
Now the time of file creation and last update are important as well but the five fields that I have outlined are necessary to recover the folders.
In my next installment I will outline the attributes of the file entry record that can define a folder entry.
- Part 1 Recovering FAT 32 With File Entry Data
- Part 2 Recovering FAT 32 With File System Markers
- Freeware Data Recovery
- Hard Drive Recovery
I’ve searched your archives and have been disappointed not to find an entry that mentions recoveries from the loss of a logical drive (FAT32). My problem may not be common but take no assumption that is is not vital to recover the data lost on a slave HD.
I have a slave drive which has 1 partition and 8 logicals (F thu M), each about 20 gigs. Suddenly, one dark and stormy night (not really, it has been quite pleasant here), my K drive was missing.
On this drive I was organizing my family photos and other personal files and suddenly, I had no K drive.
I know I don’t have the intellect to delete or remove this logical drive intentionally, but it’s gone never-the-less.
I do not have a backup for this drive as I had just started compiling the dates and events, just before this mishap occurred.
I’ve tried all the software you have for free and on track stuff as well.
Steven D, I have forwarded this to Dick Correa the author of this article and our chief software developer.