offline 은 gone 이랑 다르다

"offline SMB 경로는 macOS/cwkWaygate 가 명시적으로 마운트할 때까지 offline 인 채 있어. Ashen Reel 은 offline 경로를 보고하고 기다려."

'못 찾겠어'의 아주 다른 두 종류

NAS 영상은 완전히 다른 두 이유로 못 열릴 수 있고, 그걸 헷갈리는 게 플레이어가 조용히 진실을 파괴하는 방식이야. 공유가 지금 마운트 안 됐거나 — 파일은 멀쩡하고, 그냥 일시적으로 못 닿거나 — 파일이 해석된, 마운트된 경로에 진짜 더 이상 존재 안 하거나. 첫 번째가 offline 이야. 두 번째가 missing 이고. 걘 반대 반응을 요구하고, 게으른 fileExists() 검사는 둘 다 '없어짐' 이라 불러.

Ashen Reel 은 걜 합치기를 거부해. 마운트 안 된 공유는 offline 결과를 내: 요청이 보이게 남고, 아무것도 안 다시 쓰이고, 플레이어가 기다려. 마운트되고 닿을 수 있는 루트에서 없는 파일만 missing 이야 — 그리고 그때조차 Ashen Reel 은 Recall 기록을 다시 쓰러 안 가. offline 은 '나중에 다시 와' 야; 절대 '기억을 삭제해' 가 아냐.

일시적으로-못-닿음과 영구적으로-없어짐을 구분하고, 일시적 실패에 진실을 절대 파괴하지 마. 네트워크 딸꾹질, 마운트 안 된 드라이브, 서비스 재시작 — 이건 순간이지 판결이 아냐. 일시적 실패에 영구적인 것처럼 반응하는 게 시스템이 자기 데이터를 먹어치우는 방식이야.

구분은 enum 하나랑 정직한 분류기 하나야:

Ashen Reel 은 네트워크 자격증명을 하나도 안 갖고 아무것도 안 마운트해. 공유가 offline 일 때, 플레이어는 저장된 자격증명으로 자동 마운트 안 해 — 설계상 하나도 없어. 마운팅은 macOS 랑 파일 워크벤치 일이야. SMB 비밀번호를 조용히 저장하고 자기가 공유를 마운트하는 플레이어는 경계가 피하려고 그은 보안·소유권 문제 통째 클래스를 다시 여는 거야.

왜 이게 아카이브를 지키나

대안을 상상해봐. 백업 중에 공유가 10초 offline 으로 깜빡해. 부주의한 플레이어가 fileExists() == false 를 보고, 영상이 없어졌다 결론 내고, '도움되게' Recall 경로를 다시 쓰거나 기록을 missing 으로 표시해. 공유가 돌아와 — 이제 아카이브의 기억이 커피 한 모금보다 짧게 지속된 일시적 네트워크 이벤트에 손상됐어. offline 을 판결이 아니라 참을성 있는 기다림으로 취급함으로써, Ashen Reel 은 나쁜 10초가 진실에 영구적 흉터가 절대 못 되게 해. 일시적 실패에서의 절제가 대체 불가능한 걸 대체 불가능하게 지키는 법이야.

Code

offline 과 missing 은 반대 반응을 가진 다른 결과야·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

네 시스템에서 실패에 반응해 durable 상태를 바꾸는 에러 경로를 찾아 — 레코드 삭제, 뭔가 무효 표시, 참조 다시 쓰기. 물어봐: 그 실패가 일시적일 수 있어(타임아웃, offline 의존성, 재시작)? 그러면, 일시적 깜빡임에 진실을 파괴하고 있을 수 있어. 결과를 '일시적으로 못 닿음'(기다림/재시도, 아무것도 안 건드림)이랑 '진짜 없어짐'(강한 증거에서만 행동)으로 쪼개.

Hint

위험한 모양은 '실패 시, durable 상태를 변형' 이야. 그런 모든 자리에 물어봐: 이 실패가 10초 뒤 저절로 풀리면? 그럼 그 변형이 틀리고 되돌리기 어려우면, 일시적이랑 영구적을 합친 거야. 영구적이고 증거 잘 잡힌 결론만 진실을 바꿔도 돼.

offline 은 gone 이랑 다르다

'못 찾겠어'의 아주 다른 두 종류

왜 이게 아카이브를 지키나

Code

External links

Exercise

Progress

댓글 0