1

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.

3
  • 2
    The email client (Thunderbird) is responsible for retrieving and deleting the emails. It’s not Comcast. Does Comcast webmail have a trash or deleted items recovery feature? I’d recommend just using the webmail interface... then you don’t have to worry about things like this and can access your email anywhere. Commented May 31, 2019 at 4:34
  • 2
    For the future - there ought to be some kind of 'timer' setting in the client, 'delete mail from server after...' If you set that to at least a day, then if something similar ever happens, you could at least fetch it over webmail [if they have an interface] or just from another device. [Most of them have webmail these days because you're really dealing with an IMAP structure which is being told to behave as though it was POP3]
    – Tetsujin
    Commented May 31, 2019 at 7:25
  • 1
    @Tetsujin there is indeed and you're absolutely right. I will change it. Commented May 31, 2019 at 15:22

1 Answer 1

5

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 not1.)


1 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.

2
  • Thanks! It's Windows 7 and a desktop on a/c power. 35 emails usually takes 1 minute to download. I feel like Windows 7 itself is faster than that in writing to disk, usually. Although, since this OS crashed, it's quite possible it was malfunctioning right before the crash, so maybe disk writes were not being achieved, but POP3 commands over the net were being achieved. Worse case scenario. I wonder how Thunderbird sends those requests. Commented May 31, 2019 at 15:19
  • 2
    Writes are nearly always cached in memory first, then sorted and sent to disk all in one batch (every few minutes). It's normal behavior. Commented May 31, 2019 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .