I Found an Evernote Inside a OneNote Inside a OneDrive I Was Deleting

September 28, 2026

A few weeks ago I decided to shut down an old Microsoft account — one tied to a small IT business I ran over a decade ago, dormant for years, still quietly holding files.

The reason was simple enough. Microsoft has been wiring AI into every surface it owns, that storage was in scope, and I could not have told you what was in it. Not vaguely — at all. A decade of accumulation across machines I no longer remember configuring. The obvious response is to go through it and clean it up, and I want to be honest that I’ve never once managed that. So the alternative was to take it somewhere that can’t read it in the first place.

That turned out to be the right call for reasons I hadn’t anticipated, which is most of what follows.

Then I looked at the account and it said 11.8 GB used of 5 GB. 236%.

My first assumption was that the files had grown. They hadn’t. I checked the order history, and there it was: a Microsoft 365 subscription that renewed fine in April, then declined in May on a card I’d since replaced. The files never changed. The ceiling collapsed — 1 TB down to the free tier’s 5 GB, overnight, and I hadn’t noticed for four months.

That’s worth sitting with, because I suspect it’s common. Most “I’m out of cloud storage” panics are a billing failure wearing a capacity costume. Check the order history before you believe the storage page.

There’s a clock attached, too: go over quota and the account freezes at three months, and Microsoft may delete everything at six. I was already past the freeze. So the job became: get 12 GB out, verify it properly, and close the account.

I’d read a few guides on exactly this. Every one of them is the same shape — install rclone, configure a OneDrive remote, configure a Proton Drive remote, copy, done. Every one of them is also wrong in the same place, and none of them cover the parts that actually bit me.

The tool everyone recommends doesn’t work

rclone is the right answer for the source side. It speaks OneDrive, Dropbox, Google Drive, S3 and a dozen others with the same handful of verbs, and it gives you hashes.

The destination side is where the guides fall over. They all tell you to configure rclone’s Proton Drive backend. It’s been broken since around November 2025 — block-verification tokens changed, the retry logic is hardwired off, and failed uploads leave orphaned drafts that poison subsequent attempts. There’s an open request for someone to rewrite it against Proton’s newer SDK. Every guide I found recommends it anyway.

So: rclone to pull down, Proton’s own desktop client to push up. Slower, because the client encrypts every file before it leaves the machine, but that’s the whole point of being there.

Verification that cannot see what it’s verifying

Here’s the part I got wrong, and it’s the reason I’m writing this.

I pulled 3,837 files down. rclone check compared them against the source: zero differences. I pushed them to Proton. Then I queried the desktop client’s own state database — it keeps a SQLite file recording what actually exists server-side, which is much better evidence than a UI that says “Synced”:

Copy-Item "$env:LOCALAPPDATA\Proton\Proton Drive\RemoteAdapter.sqlite" "$env:TEMP\snap.sqlite"
sqlite3 "$env:TEMP\snap.sqlite" "SELECT Type, COUNT(*), SUM(Size) FROM AdapterTree GROUP BY Type;"

File counts matched. Byte totals matched exactly — 9,361,247,844 bytes on both sides. I opened a few files from the web interface to be sure they decrypted. Everything passed.

Then I deleted the files from OneDrive, and the cleanup step failed: directory not empty. But rclone size reported zero objects, and the folder listed as empty — while the account still showed 35 MB used.

That 35 MB was a OneNote notebook. Microsoft stores notebooks as a special object type that doesn’t appear in a normal directory listing, so rclone never saw it, never downloaded it, and never migrated it. Every check I’d run passed while being structurally incapable of noticing it.

The rule I’d write on the wall: reconcile against the provider’s own storage figure, not just your file enumeration. They answer different questions. A file listing tells you about objects your tool can see. The storage number counts everything the provider is holding. When those disagree, something exists that you’re blind to.

Same trap waits in Google Drive, where native Docs and Sheets have no real byte size until exported. Anything the listing shows with a size of -1 deserves suspicion.

Then it got worse, in an interesting way

Having found one invisible thing, I went looking for the category. I audited the finished migration for every file type that can contain other files:

About 39% of the migration by size was inside containers whose contents I had never enumerated.

Now, the honest nuance: nothing was lost. Byte-copying a container preserves everything inside it perfectly. What failed wasn’t preservation, it was discoverability — I couldn’t answer “did I capture X?”, only “did I capture the same number of files.”

Which tells you where that audit belongs. It’s not a migration-integrity step. It’s a pre-triage step. You can safely copy a container you’ve never opened. You cannot safely delete one. And I had been cheerfully proposing deletions.

The bit where I embarrass myself

Look at that table again. Fourteen Evernote exports.

I had completely forgotten I ever used Evernote.

It gets better. I opened one of the OneNote notebooks and found pages showing “Page Not Yet Available — added from another computer and hasn’t synced yet.” Content that had never reached the cloud at all, from a sync failure years old on a machine whose name was stamped all over a set of conflict folders — the kind where the hostname gets appended each time it collides, so you end up with a folder called Notebook-LAPTOP-XXXX-LAPTOP-XXXX-LAPTOP-XXXX. Three separate failures, three separate appendings, and at no point did I notice.

Chasing those pages one at a time was the wrong instinct. The right question was why pages were missing, and the answer was sitting in the filenames:

Job Search.enex    People.enex       References.enex
Car sales prep.enex   Interview Answers.enex   …and nine more

Every .enex file was named after a OneNote notebook. The entire OneNote structure was an import from Evernote, done at some point I have no memory of whatsoever. OneNote was the lossy copy. The Evernote exports were the originals, sitting in the same folder the whole time, invisible because they were containers and I was counting files.

So I extracted all fourteen — both halves, because .enex stores attachments and note bodies separately and pulling only the attachments silently loses every text-only note. What came back:

• Four notebooks that read as completely empty in OneNote had 3, 7, 10 and 1 notes in their originals.
• One notebook held 8 entries in OneNote and 17 in the Evernote export — with zero overlap. Two different rounds of the same project, years apart. Neither source was a superset of the other. I needed both, and I’d have shipped only one.

The generalizable version, which I think is the most useful thing in this whole post: when data has been migrated between tools, the newest copy is not necessarily the most complete one. Before you repair the current format, check whether the previous format is sitting in the same export.

The un-generalizable version is that I maintained two note-taking systems, imported one into the other, forgot both, and then paid a fifth company to store the wreckage for several years.

One more, because it’s a good warning

Buried in a notebook was a voice memo I’d recorded and forgotten. I’d scanned every file for audio signatures first — WAV, MP3, M4A, WMA — and confidently reported there was no audio anywhere.

It was AMR. A speech codec. Not on my list.

A signature scan proves only that the signatures you looked for are absent. It does not prove absence. I stated a conclusion my method couldn’t support, which is a more embarrassing error than missing the file.

Closing the account nearly cost me a laptop

The last step turned out to be the most dangerous, and no guide mentions it at all.

Microsoft won’t close an account while devices are registered to it — that’s reset protection, the feature that stops a stolen machine being wiped and reused. After a factory reset, Windows demands the account the device was registered to.

If that account no longer exists, that prompt cannot be satisfied.

I had two devices registered. One of them was a laptop I still use, still running, with BitLocker enabled — and it signed into Windows with the account I was about to delete. The recovery key was escrowed to that same account.

Close the account first and nothing breaks immediately. Cached credentials keep letting you in. Then one day a firmware update or a TPM reset triggers the BitLocker recovery prompt, and it asks for a 48-digit key held by an account that stopped existing months ago.

The order that avoids this:

1. Get the recovery key off the machine itself — manage-bde -protectors -get C: in an admin terminal. Take the numerical password and its key ID. The machine is the authoritative source; the account’s copy dies with the account.
2. Convert that machine to a local account while the Microsoft account still works. Afterwards its password can never be reset.
3. Cold-boot and actually sign in. The settings page reporting success is not the same thing.
4. Then remove the devices and close the account.

Two small traps in step 2. The option lives in Settings, not Control Panel — if your heading says “User Accounts,” you’re in the wrong app. And Windows hides “Sign in with a local account instead” when passwordless sign-in is enforced; turn off the Windows Hello requirement and the link reappears.

Also worth knowing: removing a device leaves a second registration behind in the Microsoft Store device list. And that list is the better inventory — mine showed five machines going back to 2020, including one the first list never mentioned.

What it actually bought me

Not money. The subscription had already lapsed back in May — the bleeding had stopped four months before I noticed the wound. All that urgency, and the account had been costing me nothing the whole time.

What it bought was the thing I went in for. And everything above is the argument for it.

I didn’t leave because Microsoft did something wrong. I left because Microsoft is wiring AI into every surface it owns, that storage was in scope, and I had no idea what was in there. Twelve gigabytes accumulated over a decade, from a business I no longer run, on machines I no longer remember configuring.

For a while I assumed the answer was discipline. Be careful what you upload. Review it now and then. Keep the sensitive things somewhere else.

Then I actually went looking, and found a voice memo I’d forgotten recording, a password vault, two copies of a disk-encryption recovery key, and an entire note-taking service I have no memory of ever signing up for.

That settles the discipline question. You cannot curate what you don’t remember putting there. Any protection that depends on me knowing the contents of my own storage is a protection that has already failed — and I just proved it over five days, with proper tooling and real effort, and still needed three passes to find everything.

So the control has to be structural rather than behavioural. Not a provider who promises not to look — a promise is a policy, and policies get revised in a changelog nobody reads. A provider who cannot look. End-to-end encryption isn’t paranoia in this context; it’s a substitute for a discipline I now have documented evidence I don’t possess.

That’s the real ledger:

• One fewer company holding a decade of my files in a form they can read
• One fewer account, one fewer login, one fewer thing to forget about for another eight years
• Four services collapsing toward one, so that next time the question “what’s in there?” has a findable answer
• And 9.6 GB pulled off a deletion clock, which was the accident that started all this

The money was never the point — which is fortunate, because there wasn’t any. Three services left to untangle. One of them, I’m told, is on a legacy plan I’ve been quietly overpaying since roughly forever, which given everything above I’m choosing to find encouraging rather than depressing.

Research and drafting assistance for this piece, including source verification, was provided by Claude (Anthropic). The migration, the mistakes, and the forgotten Evernote account are all my own.