Decoding FAT32 directory structure

[Dan Moos]

When parsing a FAT32 SDCard directory in order to display it on my homebrew computer, how do I reliably decide which entries to display, and which entries are meta data. I can tell the volume label. but after that its not so clear how to do this. Looking at the entries with a hex viewer, I can tell by eye what is an actual file or directory, but I'm not sure how to filter the meta data out.

I know how to read the attribute flags, but my test disk has entries where the attribute flags seem like they would be valid entries, but the entry clearly isn't. For instance, there is what appears to be a duplicate entry for a test .txt file on the disk. The only difference I see is that the fake entry is 0 bytes long, and It's archive flag is set. The real .txt file's entry had its archive bit set, but I cleared it in windows. Now the 0 byte length is the only difference. Yet, I feel a 0 byte file is something I should be able to display in my directory. (say I create a file on my command line, but don't do anything with it yet). So how would I know which entry to display?

There are a bunch of entries on my disk who's attribute byte is 0x0F. These entries are CLEARLY not files or directories. So is 0x0F an automatic non valid entry? seems so. There are a few other entries that are clearly not files or directories, but have some combo of attribute flags set.

Basically, how does windows decide what I see?

[SiliconWizard]

These "duplicate" entries with 0x0F attribute are the LFN entries (long file name).

[amyk]

Besides the LFNs which are ignorable (they have the volume label bit set) if all you need is 8.3, post a sample hexdump for more concrete details on how to read the directory entries.

[Dan Moos]

ok, is any entry that is attributed as a volume label, other than the actual first entry volume label, an LFN entry?

Also, there is a hidden system sub directrory listed. What is that all about? Card is NOT formated as bootable, and the proper master boot record entry reflects this.

Let me take a screen shot of my hex viewer.

[Dan Moos]

here is a screen shot of the raw hex of the directory.

I do think you guys have given me what I need, but I'm still up for more info!

[Dan Moos]

also, am I correct that the entries that begin with 0xE5 are deleted files, and thus should be ignored?

[SiliconWizard]

https://wiki.osdev.org/FAT

[mariush]

Here's some more reference :

straight from microsoft Microsoft FAT Specification: https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf

https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system

exFAT spec : https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification

[peter-h]

Not sure if this is applicable to your project, but FatFS will do the decoding for you.

In my project I have 2MB of serial FLASH (Adesto SPI 45DB) which is presented to the USB Host via USB MSC (the OS e.g. Windows sees it as a removable device, and for 2MB enforces a FAT12 layout) and FatFS is used on the firmware side to make it accessible similarly to your own code.

Ir works superbly, although there are gotchas

- windows assumes it totally owns a removable device, so it doesn't refresh it unless you unmount/remount it
- the embedded code won't see anything windows wrote until the root directory is updated (fairly obviously)

FatFS works great and I would never try doing the decoding the hard way. You can specify LFN support, directory support (I have those turned off, although you can't stop windows creating these), and other stuff.