Among one of the reasons the FAT family of filesystems is in widespread use is its simplicity, which makes data recovery easier. Writing a FAT driver/reader is a common assignment for systems programming courses, and I've done it myself too.<p>I took a quick look at the truncated image he provided, and it looks like the fields in the MBR and boot sector are OK; but things start getting weird after that.<p>The root is at cluster 2 where it normally should be (byte offset C00000 in the image), but its second entry is that all-spaces directory which claims to start in cluster 4, and furthermore its creation date is recent (2020-03-12).<p>Cluster 3 (C08000) is a directory which points to ZOOM0002.hprj, ZOOM0002_Tr1.WAV, and ZOOM0002_Tr2.WAV, its "." is correctly pointing to itself, but its parent according to ".." is at cluster 4. It is directory "ZOOM0002".<p>Cluster 4 (C10000) is a directory which contains 3 directories ZOOM0001 through 3, its "." is correctly pointing to itself, and its parent is pointing to the root (indicated with a cluster of 0). This is, according to the root, the "all spaces" directory.<p>Cluster 5 (C18000) is ZOOM0001 directory, and its "." and ".." are correct.<p>Cluster 6 (C20000) is a file, ZOOM0001.hprj<p>Cluster 7 (C28000) is a file, ZOOM0001_LR.WAV<p>In other words, everything looks OK except for that all-spaces directory in the root. According to page 25 of <a href="https://www.zoom-na.com/sites/default/files/products/downloads/pdfs/H6-Manual_0_1.pdf" rel="nofollow">https://www.zoom-na.com/sites/default/files/products/downloa...</a> that should have been named something like FOLDER01 through FOLDER10, so fixing that should make it valid again.<p>It's hard to say what happened here without knowing the state of the filesystem before the Zoom started writing to it, but the fact that the creation date/time of that nameless directory (2020-03-12 12:29) matches <i>exactly</i> with that of the first file it wrote (ZOOM0001.hprj/ZOOM0001_LR.WAV) strongly suggests that the card did not already have a corrupted filesystem beforehand, and the Zoom somehow wrote a blank name directory where it should've written FOLDER01. A search for "FOLDER" in the image yields no results either, so it's not like it wrote them somewhere else (unless it did so beyond the first 500MB of the card.)<p>I've seen embedded devices become confused and write corrupted filesystems a few times before, but they were far more egregious than this; e.g. ignoring/assuming certain fields' values would result in filesystem structures being wholesale shifted by some offset, etc. This is an unusual case because nothing about the filesystem stood out as being "obviously suspicious/non-standard", and everything except for the name was fine --- hence why 7-zip could still operate on it; it didn't care about the name.<p>The value of 1458 reserved sectors (729KB!) initially stood out, but upon further thought, that may simply be to align the first cluster with the eraseblocks of the flash, as if the Zoom really was to ignore it, the filesystem structures would've been far more mangled.