Saving a read-only file: hard error, or offer to overwrite?

[PathGao]

Is your feature request related to a problem? Please describe.

Saving over a read-only file used to behave differently per platform, because atomic_write replaces the file by renaming a temp file over it — and a rename is authorised by the directory's permissions, not the target's.

	Before
macOS / Linux	chmod 444 was ignored: the file was rewritten, and the read-only bit restored afterwards, so nothing showed the protection had been bypassed
Windows	MoveFileExW refuses a read-only destination, so the save failed

A separate PR makes all three platforms refuse, which stops the silent bypass and makes the behaviour consistent. The buffer stays dirty and a toast reports … is read-only, so nothing is lost.

Worth flagging: that removes a capability on macOS and Linux. Anyone who was editing a read-only file there and saving successfully now gets an error instead. It was arguably never correct — the app was overriding a protection the user set — but it is a user-visible change and you should be the one to decide it stands.

Describe the solution you'd like

VS Code prompts instead of failing: "Failed to save … the file is write protected" with Overwrite / Cancel, and Overwrite clears the bit, writes, and restores it. That is friendlier than a dead end, since the user usually knows exactly why the file is read-only.

Describe alternatives you've considered

• Keep the plain error (what the PR does). Nothing more to build, and the message names the cause.
• Prompt to overwrite. Needs a distinguishable error code from the backend, a confirmation in the frontend, and a force path through the save command — a small but real UI contract, which is why it is not bundled into a fix PR.
• Show read-only state in the UI before the save is attempted, so the user is not surprised at save time. Could stand alone or accompany either option above.

Happy to implement whichever you prefer.

[PathGao]

Coming back to this one with the reason it has been hard to answer, and three concrete ways out.

The question here — hard error, or offer to overwrite — cannot be answered in the UI today, because nothing on the JS side can tell a permission error from any other write failure. Every failure that crosses from Rust becomes a human-readable string, so by the time the dialog code has it, the reason is gone and only the sentence is left. #292 was the same shape: we could not tell "the file is gone" from "reading it failed once".

What it is today. PROJECT_GUIDE.md writes Result<T, String> down as the convention, and Cargo.toml has no thiserror. Two things fall out of that which are easy to miss:

• Error text is the only part of the app that is never translated. The 26-language dictionary covers every toast the frontend raises itself, because those are the failures the frontend already understands. The two that carry a backend failure are hardcoded English plus the raw string.
• The one failure that does have a type is the one with good UX. lossySaveBlocked comes back as a boolean, and that is why fix(documents): refuse to save a buffer that was decoded lossily #379 could turn it into a sentence a user can act on.

There is also a protocol nobody reads: tab_transfer.rs produces TRANSFER_FORBIDDEN / TRANSFER_NOT_FOUND / TRANSFER_HANDOFF_FAILED in five places, and nothing in src/ looks at them.

So the three options, smallest first:

1. Answer this issue alone: add a "Save As" escape hatch and close it. No architecture change. The next error that wants different UX asks the same question again.
2. Type only the file-IO family — NotFound / PermissionDenied / TransientIo / Unknown(String) — and leave everything else a string. this issue gets its dialog, kind doubles as the i18n key so the message lands in all 26 languages, and nothing else has to move.
3. thiserror + tagged enums across the board. Adding a variant then fails the frontend switch at compile time. Cost: the variant set becomes a public contract, the types get written on both sides unless we add ts-rs, and most call sites still end at Unknown(String).

I lean 2 — it is the smallest thing that answers this issue and it does not commit you to a project-wide contract. And whichever way you go, TRANSFER_* should either get a reader or lose the prefixes; a protocol with no consumer is worse than none, because the next person assumes it means something.