An editor and a filesystem can hold two different documents
Zed doesn't autosave, and an unsaved buffer looks exactly like a saved one.
Here’s something I didn’t know this morning: an editor and a filesystem can hold two different documents under one name, and neither is obliged to mention it.
I found out the slow way. Four rounds of “it’s not there” / “but I can see it” before I checked the only thing that settles an argument like that:
$ stat -c '%y %s bytes' content/first-try.md
2026-09-20 16:04:13 -0500 186 bytes
The editor said thirteen lines. The disk said 186 bytes.
What was actually going on
Two separate things were holding my text, and I’d assumed they were one thing.
The editor is a program showing me a document it’s keeping in memory. The file on disk is what’s actually saved — and it’s the only version any other program can see. When you hit save, the first copies itself onto the second. Until then they can drift apart, and nothing on screen tells you they have.
Zed doesn’t save automatically. I’d never thought to ask whether it did, because every editor I’d used before happened to. So for twenty minutes I had thirteen lines of text that existed in exactly one place — a program’s memory — while every tool I pointed at the file correctly reported an older, shorter document.
The tell was there the whole time: an unsaved tab shows a filled dot where the close button normally is. Two pixels. Completely invisible if you’re looking at your writing instead of your tabs, which is what writing is.
The bit that annoys me
Every single component behaved correctly.
The editor wasn’t lying — it showed me my text, which existed. The build wasn’t wrong — it read the file, which also existed. Nobody malfunctioned. The only broken part was my assumption that “the document” was one object, and I’d made that assumption so early and so quietly that it never occurred to me to go back and check it.
That’s a worse class of problem than a bug. A bug announces itself. This just sits there being reasonable.
What to actually do
When something you changed doesn’t take effect, resist the urge to theorise about why. Go and ask the thing itself what it currently says.
stat -c '%y %s bytes' path/to/file
That prints when the file last changed and how big it is. If the timestamp is older than the edit you just made, stop — nothing further along the chain is worth investigating, because the change you’re debugging hasn’t happened yet.
And turn autosave on, so the question stops coming up:
{ "autosave": "on_focus_change" }
Why I think this is bigger than an editor
Nobody told me this either, so I’m passing it sideways rather than down.
The shape of the mistake was: the thing I was looking at was not the thing that mattered, and it looked close enough that I never checked. Once you have that shape in your head you start seeing it everywhere, and mostly not in software.
You rehearsed the presentation; the version in the shared folder is from Tuesday. You agreed the deal on a call; the contract says something slightly different. You’ve been revising from your notes; the exam is set from the syllabus. Every one of those is an editor buffer and a file on disk, and every one of them is survivable if you know to go and check the copy that counts.
The useful reflex isn’t be more careful. It’s much narrower than that, and therefore much easier to actually do: know which copy is authoritative, and go look at that one. It took me four rounds of arguing with a file to learn it, and I’d rather you got it for free.