PC crashed while downloading POP3 email. Are those emails are gone?

Question

Thunderbird was in the midst of downloading 35 emails received in the last 15 hours from an account configured as POP3.

PC crashed in the middle.

Upon reboot, Thunderbird does not have those new emails locally. And it thinks it's done. It does not re-download them.

It's re-downloading newly received emails fine since.

I have the account set to NOT Leave messages on server.

And, sure enough, the server (Comcast, checked via webmail) has no emails. Inbox is empty.

It seems like there ought to be some interlock, like, mail server waits for mail client to acknowledge download of email message, and only then delete that message.

Instead it seems like mail server got POP request, put all emails in a download queue, and deleted the messages from the inbox, regardless of whether the client succeeded downloading or not.

I ask you find a flaw in my reasoning, hoping that then these lost emails are somewhere I can retrieve them.

EDIT: this is on Windows 7 desktop, A/C wall power.

Answer 1

It seems like there ought to be some interlock, like, mail server waits for mail client to acknowledge download of email message, and only then delete that message.

In standard POP3 servers, deletion is indeed a separate command. First the client sends RETR for every message UID it wants to download, then it sends DELE for every message UID it wants to delete. (The download happens over the same connection.)

(With some clients it's "RETR 1, RETR 2, RETR 3... DELE 1, DELE 2, DELE 3...", with other clients it's "RETR 1, DELE 1, RETR 2, DELE 2, RETR 3, DELE 3...", but that doesn't really change the fact that DELE is still a separate command that happens after retrieval.)

If the POP3 server itself deletes messages after retrieval, that's not standard POP3 behavior.

---

That said, it is possible that the client sent a batch of commands (RETR+DELE) all in one shot, without actually waiting for each previous message to finish downloading, and that would certainly be a design flaw in the client.

But it is far more likely that the client did successfully download those messages and save them to filesystem – but the OS hadn't actually written the pending updates to disk yet when it crashed.

That's unfortunately a common issue, sometimes just a few seconds of data are lost after crash, in other cases it could be several minutes. (It depends on OS, on the filesystem, on whether it's AC-or-battery-powered, and on whether the program manually requested a data sync or not¹.)

---

¹ Why would the program not use fsync() when writing important data to disk? It could be laziness, or it could be (at least on Linux) that the sync operation is much too slow for everyday use.