[Epic 4G General] mkasick:
The Wikipedia page on the FAT file system explains how it works a bit, although I imagine there's more illustrative examples out there. But basically, file data blocks are stored in clusters, and there's a table that contains entires for each cluster in the file system, where each table entry contains the index (location) of the next cluster, if that cluster is part of a file.

So it's quite possible that file data blocks for a given file are written out fine, but when the FAT is modified while writing/modifying a file that happens to be adjacent to it, the cluster indexes for the existing file are corrupted.

This is likely the result of a single corrupt cluster index. The corrupt index points to a cluster in the middle of the mp3, and if it were accidentally changed to "0" then (roughly) half the file is lopped off. Later, when fsck_msdos runs and scans the FAT and directory entries, it sees a chain of valid clusters that's not attached to any file. So it gives it a new file name and stuffs it in LOST.DIR.

If the entire file was in LOST.DIR, it sounds like a corrupt directory entry. That's a bit more suspicious, particularly if other part of the directory entry (name, time, etc.) were OK.

One way orphaned files happen is when a file is deleted, and it's corresponding directory entry is removed, but the updated FAT hasn't been written out yet. The phone shouldn't be doing this too often, as long as the SD card is always properly unmounted (e.g., phone is properly shutdown). I could see computers doing this rather frequently, particular if the USB device isn't "safely removed".

Afterall, orphaned files in that instance aren't a safety/corruption issue. There's just less free space in the file system until a fsck or other consistency check tool is run.

In any event, I don't find the existence of these alone to be terribly surprising, especially in absence of missing files or other more significant corruption.

In almost all instances I expect those are due to data corruption on the /data file system, which, with ext4 can often happen on a phone crash or battery pull. Even with a journal, ext4 uses a delayed allocation scheme whereby newly allocated data may not be committed up to a few minutes after being "written", a window during which if the phone crashes, those files will experience data loss.

As an anecdote: I usually end up with 2-3 orphaned files in LOST.DIR everytime I do a kernel upgrade, which I issue from within Android using redbend_ua without a clean shutdown. But I've never seen more obvious corruption. And I never see files in LOST.DIR after preforming a clean shutdown and clean unmounts.

You may be right about that, particularly if the affected files are thumbnails or related to the media cache.

Still, I suspect if the problem were somewhat-spread among Epic owners here, we'd see a lot more posts about SD card corruption.

Since most of those activities don't result in SD card mutations, I suspect not. Also, it doesn't look like "the problem" is confined to users to root and custom ROM.

A few more notes:

If it always happens after a phone crash, random reboot, etc, it's just file system corruption and there's little that can be done. Amusingly, RFS is essentially a "journaled FAT" and would solve that problem, but it's not

used on SD cards on Samsung devices, which otherwise seems like a perfectly appropriate use for it.

I'm suspicious of it being a bug in the file system driver. If it was, corruption would be discovered at random times instead of specifically after a reboot or remount event, which is when folks seem to report it happening.

It could be a bug in fsck_msdos. I'd be a bit surprised if it was, but I don't think fsck_msdos is used particularly often outside of Android or other embedded devices, so the code may not be as well vetted as, say, fsck.ext3. One way to tell would be to disable fsck_msdos entirely and see if data still goes missing.