In my last installment I described the file entry record and its on-disk format. I used a ‘C’ structure to denote the different fields of the record and defined which five are most important to us when trying to recover a FAT32 file system where all the main file system components have been destroyed or corrupted. In this installment I will describe what is unique about the file entry record for a folder entry and how we can use that as a filter for the software logic.
The first two elements of the file entry record are the file name which is eight bytes, and the file extension which is 3 bytes. For the beginning of every folder the first file entry record has the file name “. “, that is, a period, followed by ten spaces. In other words the first eleven bytes of the beginning of a sector that stores the beginning of a folder are static and are always the same. Now this fact is important in as much as we can look for this particular attribute in a sector and when we find it there is a very good possibility that we are looking at the beginning of a folder. With the being said it is always better to try and refine a filter in order to make sure that you have in fact found the beginning of a folder. Oddly enough, the second file entry record had the file name “.. “, that is, TWO periods followed by nine spaces.
Each file entry record is a static thirty-two bytes long. That being said we can now assert this. If bytes zero through seven of a sector are a period followed by ten spaces and bytes thirty-two through forty-two of the same sector is two periods followed by nine spaces then there is a high probability that we have found the beginning of a folder.
The pseudo logic for this might look like:
while(1)
{
if(ReadSector FAILS) break;
if(FileEntry Record Zero equals “. ” && FileEntry Record One equals “.. “)
{
We have a valid folder
}
}
The chances of a sector slipping by that may not be a folder entry is very slim. This is good in as much as it can be difficult to define a filter that will give you the most optimal results without flooding you with a set of worthless data.
In my next installment I will explain what this ‘.’ and ‘..’ mean. If there are some old DOS command line users out there I am sure you are well aware of what I am talking about. Until next time…
Related Articles:
- Part 1 Recovering FAT 32 With File Entry Data
- Part 2 Recovering FAT 32 With File System Markers
- Part 3 FAT32 Recover File Entry Table On-Disk Layout Using a C Structure
- Freeware Data Recovery
- Hard Drive Recovery
I’m impressed! You’ve managed the almost ipsmosilbe.