Graceful handling + feedback when a saved file/folder path is stale (deleted or moved) #7

Problem

The "Show in folder" / "Open" actions can fail silently when the target path no longer exists — the saved file was deleted or moved, or a folder was removed. The user clicks and nothing visible happens.

Today (works, but degrades poorly)

Every reveal/open is wrapped in try/catch → diag.error(...), so nothing crashes — but a failure is invisible to the user (only a diagnostics entry). Surfaces in ui/src/main.ts:

• Show in folder (result + history) → revealSaveTarget(): with a saved file it calls revealItemInDir(lastSavedPath) directly. If that file was deleted/moved, the reveal fails (or opens an unexpected location, OS-dependent) and there is no fallback to its parent folder — which usually still exists.
• Advanced → Save folder "Open" and About → app-data / log "Open" (openAppDir) → revealItemInDir(dir); if the dir is gone, silent fail.

When the file does exist we correctly reveal/select the file in its folder. The folder-creation path is already robust (ensure_dir + the Rust write_* commands create_dir_all). The gap is specifically the stale-path case + the lack of user feedback.

Proposal

1. File-reveal fallback: if revealing the saved file fails, fall back to ensure_dir(parentFolder) + reveal the folder. Only if that also fails, surface a message.
2. Feedback instead of silence: flash the button on failure (reuse the existing flash() helper) — e.g. "File moved or deleted — opened the folder" / "Folder not found."
3. Apply consistently across revealSaveTarget, openAppDir, and the Advanced save-dir open. Consider an existence check before reveal so behavior is deterministic across OSes.

Notes

• Future work — capturing for later.
• Local-only, no network (consistent with the app). Prior art: openUrlExternal already has a window.open fallback.

Source: user feedback — stale/deleted save paths.