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.
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.
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).
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".
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.
Cluster 5 (C18000) is ZOOM0001 directory, and its "." and ".." are correct.
Cluster 6 (C20000) is a file, ZOOM0001.hprj
Cluster 7 (C28000) is a file, ZOOM0001_LR.WAV
In other words, everything looks OK except for that all-spaces directory in the root. According to page 25 of https://www.zoom-na.com/sites/default/files/products/downloa... that should have been named something like FOLDER01 through FOLDER10, so fixing that should make it valid again.
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 exactly 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.)
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.
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.
thanks a lot for dissecting this i was hoping for this ;) If i recall correctly the recording device could read those files without a hitch too. that's probably because it ignored the malformed name too or is it? i am a bit confused on how the device knew where to look at to find those files if not by the name of the parent directory.
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.
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).
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".
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.
Cluster 5 (C18000) is ZOOM0001 directory, and its "." and ".." are correct.
Cluster 6 (C20000) is a file, ZOOM0001.hprj
Cluster 7 (C28000) is a file, ZOOM0001_LR.WAV
In other words, everything looks OK except for that all-spaces directory in the root. According to page 25 of https://www.zoom-na.com/sites/default/files/products/downloa... that should have been named something like FOLDER01 through FOLDER10, so fixing that should make it valid again.
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 exactly 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.)
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.
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.