Read-Only Means Read-Only (and You Prove It)

"Source media is immutable from the player. Every code path, including screenshots and subtitle handling, writes outside the source directory."

A Promise Is Only as Real as Its Proof

"The player never modifies your files" is easy to say and easy to violate by accident. A screenshot saved next to the video. A subtitle cache written into the source folder. An 'optimize' pass that rewrites a container. A metadata tag helpfully added. None of these feel like vandalism while you're coding them — and every one of them breaks the single promise a player over someone's irreplaceable archive must keep.

Ashen Reel makes the promise concrete: every write path goes outside the source directory. Screenshots land in a destination the user chose. Caches live in the app's own Caches folder. Local state lives in Application Support. The source folder is a place the player reads from and never, ever writes to.

Prove It With a Before-and-After Audit

The way you keep a read-only promise honest is to test it like an attacker would: hash the source, put the player through its most write-tempting paces — open, seek, screenshot, load external subtitles, crash and recover — then hash again and demand they match. This runs on every corpus item, silently, as the most important test in the suite.

Every write goes outside the source, and a before/after audit proves it. Don't just intend to be read-only — verify it. A checksum and modification-time comparison before and after turns a good intention into a checkable fact, and catches the accidental write you didn't know you'd made.

The audit is a handful of shell lines, and it's the difference between hoping and knowing:

The sneaky mutations aren't the obvious ones. Nobody means to delete a file. The accidental writes are subtle: a bumped modification time from opening with the wrong flags, an extended attribute macOS tacks on, a .DS_Store or sidecar dropped in the folder, a 'last opened' timestamp written back. The audit checks hash AND metadata AND the directory contents precisely because the dangerous mutations hide in the details.

Even Screenshots Respect It

Screenshots are the tempting exception — surely a screenshot is a new file, not a mutation? Yes, and Ashen Reel still routes it outside the source directory, to a destination the user picks and can reveal. It preserves the source's high bit depth with lossless PNG rather than quietly downsampling, and it bypasses subtitle compositing when no subtitle is showing. A screenshot creates something new somewhere safe; it never leaves a footprint next to the original. The read-only promise has no exceptions, not even the convenient ones.

Code

The source-immutability audit — hope becomes a checkable fact·bash

# Prove the player is read-only: hash before, exercise it hard, hash after.
src="$1"   # a representative corpus file (bytes never enter git)

before=$(shasum -a 256 "$src" | awk '{print $1}')
mtime_before=$(stat -f %m "$src")
list_before=$(ls -A "$(dirname "$src")")

#  ... open in Ashen Reel: play, seek, screenshot, load external subs,
#      force-quit and recover, close ...

after=$(shasum -a 256 "$src" | awk '{print $1}')
mtime_after=$(stat -f %m "$src")
list_after=$(ls -A "$(dirname "$src")")

if [ "$before" = "$after" ] && [ "$mtime_before" = "$mtime_after" ] \
     && [ "$list_before" = "$list_after" ]; then
  echo "PASS: source bytes, mtime, and folder contents all unchanged"
else
  echo "FAIL: the player left a footprint on the source"
fi

Exercise

Pick a program you've written that reads user files it doesn't own. Write a before/after audit: hash the input, run your program's read paths, hash again, and also check the modification time and the folder listing. Run it. Did anything change that you didn't expect — an mtime bump, a temp file, an added attribute? If your program can't pass a strict read-only audit, find the write and move it somewhere you own.

Hint

Read-only isn't 'I didn't call write().' It's 'the hash, the mtime, and the directory listing are all identical afterward.' Opening a file with the wrong mode, or a library that touches metadata, can fail that audit without a single explicit write in your code. Test the whole footprint, not just the bytes.

Read-Only Means Read-Only (and You Prove It)

A Promise Is Only as Real as Its Proof

Prove It With a Before-and-After Audit

Even Screenshots Respect It

Code

External links

Exercise

Progress

Comments 0