Case Study 1 — The Videographer's Reformatted Card

A wedding videographer formatted the wrong card in-camera, wiping the ceremony stills and three 4K clips. Because she stopped instantly and the work was done image-first, almost everything came back — but the file system, not hope, decided exactly what. A study in how exFAT mechanics turn into an honest promise.

Background

A second shooter at a wedding studio brought in a 128 GB exFAT SD card. Mid-reception, swapping cards in a dim venue, she selected Format card in the camera menu on the wrong card — the one holding the just-shot ceremony: roughly 600 RAW+JPEG stills and three 4K video clips, including the twelve-minute processional and exchange of vows. She realized within seconds, powered the camera off, and did not touch the card again. There is no other copy; a wedding cannot be reshot.

The intake notes captured what matters: SanDisk Extreme Pro 128 GB, exFAT, physically sound, reads cleanly in a card reader, no errors. Condition received: powered off, in its case, received 2026-05-30 from the studio owner in person. The job was clearly logical, not physical — an accidental format, not a failed card. Expectations were set before any quote: most stills almost certainly recoverable with names where the directory survived; long video clips uncertain, because video is large and tends to fragment.

That last sentence mattered more than it looked. A camera shooting stills writes each photo to the card in a single, uninterrupted burst, so a still almost always lands on consecutive clusters. A long video, by contrast, is written incrementally over minutes while the camera fills and flushes buffers, and it tends to scatter across whatever clusters are free at each moment. The same accidental format would therefore hand back the stills cleanly and fight us on the longest clip — and saying so up front, before money changed hands, is the difference between a satisfied client and an ambush at delivery.

The recovery

Step one, before anything else, was to image the card through a USB write-blocker, exactly as you would a hard drive:

sudo dcfldd if=/dev/sdc of=card.dd bs=4M hash=sha256 \
     hashlog=card.sha256 conv=noerror,sync status=on
sha256sum card.dd
# 2f9a47c1e0b8d6a3...  card.dd   (recorded; the card now goes back in its case)

All work proceeded on card.dd. The format had written a fresh, empty exFAT boot region, allocation bitmap, and root directory — but, as with a quick format, it had not touched the data area where the photos and video lived.

exFAT records allocation in a separate bitmap and, crucially, only stores a FAT cluster chain for files that are fragmented; contiguous files are flagged "no FAT chain" in their directory entry and are described by a start cluster and a length alone. Each file in exFAT is represented not by one 32-byte entry but by a directory entry set — a File entry, a Stream Extension entry (holding the valid data length, the first cluster, and the "no FAT chain" flag), and one or more File Name entries. On deletion, exFAT clears the high bit of each entry's type byte (the "in use" bit, 0x85 → 0x05 for the File entry) and frees the corresponding bits in the allocation bitmap. The bytes of the set — name, length, first cluster, fragmentation flag — otherwise remain.

The format that orphaned these entries behaved like a quick format: it wrote a fresh, empty root directory and bitmap but did not scrub the regions where the old directory and the file data lived. So residual directory entry sets from the old root and subfolders survived wherever the small new directory had not landed on top of them — and with them the start clusters and lengths needed to read the files straight back.

Pointed at the image, R-Studio reconstructed the old directory tree from those residual entries and sorted recovered items into tiers. The result split exactly along the fragmentation line the file system dictates:

Recovered (metadata intact, original names):
   591 / 600  stills (.ARW + .JPG)   contiguous — byte-perfect
     2 / 3    video clips            short, contiguous — play start to finish
Reconstructed by carving (content only, names lost):
     1 / 3    video clip  -> ceremony_processional.MOV  PARTIAL (head only)
       9      stills       -> small JPEGs overwritten by the new directory

The 591 stills came back perfectly: each photo is written by the camera in a single burst to consecutive clusters, so even with the chain gone, reading from the recorded start cluster for the recorded length reproduces the file exactly. The two short clips were likewise contiguous and played start to finish.

The twelve-minute ceremony clip was the hard case. A long 4K recording is written over minutes while the camera juggles buffers, so it fragmented across the card — and exFAT keeps a FAT chain only for fragmented files, a chain the format had cleared. With the start cluster known but the jumps lost, carving (Chapter 7) recovered the opening of the file from the header forward; the video played cleanly for the first fragment, then corrupted at the first boundary where the clusters jumped somewhere the carver could not follow. The studio received a playable opening of the processional and an honest explanation of why the rest would not reassemble.

The analysis

  1. Image first, even a memory card, even in a hurry. Cards fail, and recovery is iterative — you will run scans, adjust, and re-run. Every one of those passes ran against card.dd, so the irreplaceable original was read exactly once and then set aside. Had a scan gone wrong, the fix was to re-derive a clean copy from the image, not to gamble the only original a grieving couple's memories live on.

  2. The file system, not optimism, sets the promise. exFAT's design — bitmap allocation, a FAT chain only for fragmented files — is why 591 contiguous stills were byte-perfect and one fragmented clip was not. Knowing that before quoting let the studio be told the truth up front instead of being disappointed at delivery.

  3. Stopping immediately is what made the numbers good. The single most destructive thing after an accidental format is to keep using the volume. Powering the camera off within seconds meant nothing new was written over the orphaned data; the nine stills that were lost fell under the small new root directory, the only region the format actually overwrote.

  4. Carving is the fallback, and it cannot reassemble a fragmented clip. When metadata gives out, you carve content by signature — but a carver follows bytes forward from a header and has no map of where a fragmented file jumped. The partial ceremony clip is theme #5 made concrete: knowing the limit, and naming it, is part of the craft.

  5. A partial result, delivered honestly, is still a professional result. The studio got 593 of 600 stills and two of three clips perfect, plus a labeled partial of the third — not a vague "we got most of it." The delivery manifest hashed every returned file so the studio could prove to the couple exactly what was recovered and what was not.

Discussion questions

  1. The camera offered "Quick format" and a "Low-level format" option. How would the outcome have differed if the videographer had chosen the low-level option, and why?
  2. Why image the card to a file at all, rather than simply running the recovery tool directly against the card through a write-blocker? Give two reasons specific to this job.
  3. ⭐ The ceremony clip played for one fragment and then corrupted. Explain, in terms of exFAT's "FAT chain only for fragmented files" rule and how a signature carver works, exactly why the head was recoverable and the remainder was not — and what (if anything) could in principle reassemble it.
  4. The couple cannot reshoot the ceremony. Draft the two or three sentences you would say to the studio to communicate the partial video result clearly, honestly, and without false hope or needless alarm.
  5. If the camera had recorded to an internal SSD with TRIM rather than to a plain SD card, how might the result have changed, and which chapter would you consult to set expectations?