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
- 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.
- 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."
- 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.
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 inui/src/main.ts:revealSaveTarget(): with a saved file it callsrevealItemInDir(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.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 Rustwrite_*commandscreate_dir_all). The gap is specifically the stale-path case + the lack of user feedback.Proposal
ensure_dir(parentFolder)+ reveal the folder. Only if that also fails, surface a message.flash()helper) — e.g. "File moved or deleted — opened the folder" / "Folder not found."revealSaveTarget,openAppDir, and the Advanced save-dir open. Consider an existence check before reveal so behavior is deterministic across OSes.Notes
openUrlExternalalready has awindow.openfallback.Source: user feedback — stale/deleted save paths.