Ask how do cameras write files and most people picture one save operation, like dragging a document onto a USB stick. It is not one operation. Every photo and every video frame passes through four separate writes on the card, and the capture only becomes a real, visible file at the last of them. Power can fail between any two, and each failure point produces a different symptom.
The rule worth keeping: the file the camera has not yet closed is the only one normally at risk. Understand the sequence and you can predict what an interrupted recording will look like, and whether it is worth scanning at all.
The Four Writes Behind Every Capture
A still and a video share the same plumbing. The difference is one write per shot versus thousands per second.
The sensor produces data, the image processor encodes it — JPEG or HEIF for photos, H.264 or H.265 for video — and the result lands in a buffer. The buffer exists because flash is written in whole pages rather than arbitrary bytes, and cannot be written at the speed the processor produces data. On the card side, three components take part: the NAND flash chips that store charge, the controller running the Flash Translation Layer (FTL) that maps logical addresses to physical pages, and the file system — FAT32 or exFAT on almost every consumer camera — that the camera can actually address. The camera never talks to flash directly, which is why an identical logical write can take wildly different amounts of time depending on how much internal cleanup the controller has queued.
Allocation Happens Before Any Data Moves
Before a single byte of image data moves, the camera claims space for it.
For a photo, it requests enough clusters for the expected file size. For video it cannot know the final size, so it allocates incrementally as the clip grows: in FAT32 by updating the File Allocation Table, in exFAT by updating an allocation bitmap and a directory chain. A cluster is marked in use the moment it is claimed, not when data lands in it. If the camera dies here, the card appears to have less free space than the file count explains, because no directory entry was ever created to point at that space. A normal format reclaims it, and nothing of yours is in it yet. The file name is chosen here too, by reading the highest existing number in the directory and incrementing it.
The Payload Write and the Write-Back Cache
The payload write is the largest and slowest stage, and it is where expectations diverge most sharply from reality.
When you press the shutter, the camera writes to its buffer, updates the display, and reports success. It has not necessarily written anything to the card. Most cameras use write-back caching: the buffer is flushed in batches, and the visible saved state means queued, not committed. That is why a camera can appear to have stored a burst and then lose the last frames when the battery is pulled.
This is the first counterintuitive point on this page. The byte count on the card is not evidence that a file is complete. A JPEG’s structural markers arrive long before the file finishes, so a scanner can identify a photo as present while the payload is still truncated, which is exactly how partially gray or striated images are produced. The same timing in video leaves a clip that ends mid-frame with no index, because the earliest frames spend longest on the card and are the most likely to have reached NAND.
The Directory Entry Is the Moment of Truth
The directory entry is written last, and everything about the resulting failure depends on it.
An entry is a small record holding the file name, extension, attributes, timestamps, starting cluster, and file size. Until it exists, the file does not exist as far as any camera, computer, or recovery tool can tell, no matter how much image data is sitting in the flash chips. Payload first, index second: that ordering produces two mirror-image failure modes that users constantly confuse.
If the payload completed and the entry never committed, the clusters hold a perfectly good file that nothing points to. This is the lost-file case, and it is the more recoverable of the two, because the data is complete and only the map is gone. If the entry partly committed and the payload flush was cut short, the reverse happens: a file appears with a plausible name and either zero bytes or a truncated size. This is the broken-file case. It looks simpler, but it can be harder, because the entry may point at a start cluster whose contents are incomplete.
Video adds a third layer. The container’s index atom, usually moov for MP4-family formats, is generally written when the file closes, which is also when the size field in the directory entry is finalized. An interrupted recording therefore commonly leaves a normal-looking file and a duration the player reports as 0:00. That pattern has its own workflow, covered under repairing a missing moov atom.
What a Power Cut Destroys at Each Stage
Work back from what you actually see to the stage that was interrupted.
| Stage interrupted | What is already on the card | What you see afterward | Recoverability |
|---|---|---|---|
| Allocation | Clusters marked used; no data, no entry | Free space lower than the file count explains | High; that space holds nothing of yours yet |
| Payload write | Clusters marked used; partial or full data; no entry | Clip simply absent; folder one file short | High — data present, only the pointer is gone |
| Directory entry | Complete payload; entry partial or malformed | A file with 0 bytes, 0:00 duration, or no thumbnail | Medium — content present, index must be rebuilt |
| Allocation table | Data and entry coherent; FAT or bitmap stale | Card will not mount, or mounts with an empty folder | High with a scanner that reads the raw device |
| Dismount and flush | Everything committed | Nothing lost unless the card was pulled mid-flush | High, provided the card is not written to again |
Note the asymmetry between the second and third rows: a missing file is usually the better news, and a present-but-broken file the worse news. That inversion is the second counterintuitive point here, and it is why diagnosis should follow the symptom rather than whether a filename is visible.
Why the Last Metadata Steps Decide What Survives
FAT32 and exFAT share the write-then-index ordering but differ in how much redundancy stands between you and a broken volume.
FAT32 keeps two copies of the allocation table and a fixed-position root directory. That redundancy is a recovery asset: if one copy is damaged, the other can often be parsed. Its weakness is the 4 GB per-file ceiling, which is why long recordings are split into chapters. exFAT drops the duplicate table and the fixed root in favor of an allocation bitmap and a directory that grows as a cluster chain, which handles any file size but centralizes the metadata, so damaging the wrong structures makes a volume unrecognizable rather than merely degraded.
Neither file system journals. NTFS and APFS keep a log of pending metadata changes and can roll an incomplete transaction back after a crash; FAT32 and exFAT have no such log, so an interrupted metadata write is simply an incomplete write with nothing to recover it from. That is the structural reason camera cards corrupt more readily than computer drives built on the same flash. The mount behavior of each is compared in what file system cameras use.
The reassuring consequence of the ordering is that failures are almost always local: each file is closed and indexed before the next begins, so a crash during a long take typically costs the final chapter and nothing else. The exception is damage to a shared structure. If the allocation table update was mid-flight when power failed, files can overlap in the same clusters, or the chain linking a folder to its continuation can break. The camera then refuses to mount the volume and offers to format it, and accepting that offer converts a recoverable logical problem into an unnecessary overwrite.
The correct first step is always the same and costs nothing: stop writing to the card. The mistakes that turn a good situation into a hopeless one are catalogued under safe removal and card handling, and the deeper reason a deleted file survives is in why deleted photos can be recovered.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
The three possible outcomes follow from the stages above. Files whose payload completed but whose entry never committed come back in full. Files whose index was cut short come back playable once the recovered portion is re-encoded. Files whose clusters were later reused do not come back at all, from any tool. If the symptom is a card that will not mount, start with the camera card emergency guide before running anything that writes to the volume.
Frequently Asked Questions
Why does a photo disappear when my camera said it saved it?
Because the camera reported success when the image entered the write-back buffer, not when it reached the card. If power was lost or the card was pulled before the buffer drained, the payload may never have been flushed and no directory entry was written.
Can I recover a video that shows 0:00 but has a normal file size?
In most cases, yes. That pattern means the payload was written but the index atom was not, which happens when a container is never closed properly. The frames are on the card; only the structure that tells a player how to read them is missing.
Does pulling the card out before turning the camera off lose the last photo?
Often, yes, if the camera was still flushing its cache. Power the camera down, wait for the write indicator to stop, and only then remove the card. Cameras flush on an orderly shutdown; they do not necessarily flush when the card is pulled.
How fast does a camera actually commit a file?
A JPEG usually commits within a few hundred milliseconds of the buffer flush, which is why burst shooting fills the buffer and then slows down. A video is finalized — index written, size field set — only when recording is stopped cleanly.