Offline Is Not the Same as Gone

"An offline SMB path remains offline until macOS/cwkWaygate mounts it explicitly. Ashen Reel reports an offline path and waits."

Two Very Different Kinds of 'I Can't Find It'

A NAS video can be un-openable for two completely different reasons, and confusing them is how a player quietly destroys truth. Either the share isn't mounted right now — the file is perfectly fine, just temporarily unreachable — or the file genuinely no longer exists at its resolved, mounted path. The first is offline. The second is missing. They demand opposite responses, and a lazy fileExists() check calls both of them 'gone.'

Ashen Reel refuses to collapse them. An unmounted share yields an offline outcome: the request stays visible, nothing gets rewritten, and the player waits. Only a file that's absent from a mounted, reachable root is missing — and even then Ashen Reel does not go rewrite Recall's record. Offline is a 'come back later'; it is never a 'delete the memory.'

Distinguish temporarily-unreachable from permanently-gone, and never destroy truth on a transient failure. A network hiccup, an unmounted drive, a service restart — these are moments, not verdicts. Reacting to a transient failure as if it were permanent is how systems eat their own data.

The distinction is one enum and one honest classifier:

Ashen Reel owns no network credentials and mounts nothing. When a share is offline, the player does not auto-mount it with stored credentials — it doesn't have any, by design. Mounting is macOS's and the file workbench's job. A player that quietly stored SMB passwords and mounted shares on its own would be reopening a whole category of security and ownership problems the boundary was drawn to avoid.

Why This Protects the Archive

Picture the alternative. The share blips offline for ten seconds during a backup. A careless player sees fileExists() == false, concludes the video is gone, and 'helpfully' rewrites Recall's path or marks the record missing. The share comes back — and now the archive's memory is corrupted by a transient network event that lasted less than a coffee sip. By treating offline as a patient wait rather than a verdict, Ashen Reel makes sure a bad ten seconds can never become a permanent scar on the truth. Restraint under transient failure is how you keep irreplaceable things irreplaceable.

Code

Offline and missing are different outcomes with opposite responses·swift

enum OpenOutcome {
    case opened
    case offline(path: String)   // share not mounted -> WAIT, touch nothing
    case missing(path: String)   // mounted + reachable, but the file truly isn't there
}

func classify(_ path: String, rootMounted: Bool) -> OpenOutcome {
    guard rootMounted else { return .offline(path: path) }   // unreachable != gone
    guard FileManager.default.fileExists(atPath: path) else {
        return .missing(path: path)                          // genuinely absent
    }
    return .opened
}

// .offline NEVER rewrites the path, NEVER auto-mounts, and NEVER tells Recall
// the video is missing. It waits for macOS / the file workbench to mount the
// share, then retries. A ten-second outage can't scar the archive's memory.

Exercise

Find an error path in your system that reacts to a failure by changing durable state — deleting a record, marking something invalid, rewriting a reference. Ask: can that failure be transient (a timeout, an offline dependency, a restart)? If yes, you may be destroying truth over a temporary blip. Split the outcome into 'temporarily unreachable' (wait/retry, touch nothing) and 'genuinely gone' (act, from strong evidence only).

Hint

The dangerous shape is 'on failure, mutate durable state.' Ask of every such spot: what if this failure clears itself in ten seconds? If the mutation would then be wrong and hard to undo, you've conflated transient with permanent. Only permanent, well-evidenced conclusions get to change the truth.

Offline Is Not the Same as Gone

Two Very Different Kinds of 'I Can't Find It'

Why This Protects the Archive

Code

External links

Exercise

Progress

Comments 0