loss of emails when disk is full

REOPENED
Unassigned

Status

defect
--
critical
REOPENED
3 months ago
3 months ago

People

(Reporter: buecher, Unassigned)

Tracking

({dataloss})

Firefox Tracking Flags

(Not tracked)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

total loss of inbox by the following events on Win 10. Happened three times in 2018/2019, so it is reproducible:

Windows downloads something (?? updates??) and brings C:drive to exactly 0 bytes. (This is new on Win 10, before, it always left a few MB).

Actual results:

inbox.msf is gone. Inbox no longer displayed. Emails are on imap server, but without tags (not stored on this specific imap server). My addon to backup tags no longer works since some time due to TB code changes, so I have no recent backup of tags.

Inbox file can be loaded as local folder. But all attempts to put it into the imapmail folder result in TB deleting it on next start. See one of the recent posts of others in TB forum which reports the same, it is impossible to get inbox file back for imap account.

Expected results:

This is orignated by Windows, but if it happens to others, their anger will go against TB. TB should not write anything if harddisk space = 0.

Actually, I noticed C being 0, emptied some space, but apparently TB was faster with some autosave.

My special worry is that it propagates to the server by TB reporting inbox is empty and server deleting all emails and then propagating to all other TB's logged in to that account.

That recently happened to me on another subfolder where TB suddenly reported in status line that it is deleting the folder and it is now gone everywhere (including server). I wasn't fast enough to pull network cable on imap server and other PC's. But that might be another bug - I did not press any delete.

OS: Unspecified → Windows 10
Hardware: Unspecified → x86

(In reply to klaus from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

total loss of inbox by the following events on Win 10. Happened three times in 2018/2019, so it is reproducible:

Windows downloads something (?? updates??) and brings C:drive to exactly 0 bytes. (This is new on Win 10, before, it always left a few MB).

Why would you contniue operating under this situation? (I guess that's a different issue)

Actual results:

inbox.msf is gone. Inbox no longer displayed. Emails are on imap server, but without tags (not stored on this specific imap server). My addon to backup tags no longer works since some time due to TB code changes, so I have no recent backup of tags.

Inbox file can be loaded as local folder. But all attempts to put it into the imapmail folder result in TB deleting it on next start. See one of the recent posts of others in TB forum which reports the same, it is impossible to get inbox file back for imap account.

Several bugs in the query https://mzl.la/2UoEjtK - bug 1169252 is a good match

Severity: normal → critical
Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Component: Untriaged → Backend
Keywords: dataloss
Product: Thunderbird → MailNews Core
Resolution: --- → DUPLICATE
Summary: loss of emails by disk overflow → loss of emails when disk is full
Duplicate of bug: 1169252

This is not bug 1169252, which is about some simpler stuff in nsMsgMailNewsUrl.cpp.

Comment 0 specifically mentioned databases (albeit only sql) which should be handled differently. I have fixed that description to also mention mork (msf), which also needs a completely different fix (it can't be fixed with MsgNewSafeBufferedFileOutputStream).

In case of .msf and .sqlite files being transactional, we probably just need to stop appending further transactions to the file if disk is full, losing new updates, but must not lose the whole file, as described here.

For example for POP3 downloading into Inbox (not the msf, but the mbox file), we always keep several MB of free space and refuse to download new message until space is freed.

Status: RESOLVED → REOPENED
Component: Backend → Database
Ever confirmed: true
Resolution: DUPLICATE → ---

You've lost me about comment 0 mentioning sql, and any change to the description (or summary).

But indeed we shouldn't lose the whole file, and have that somehow reflected back to the server. AND something should give the user simple, non-technical feedback.

I meant bug 1169252 comment 0 :)

We should somehow stop syncing/downloading new messages from IMAP if disk is almost full. We do it for POP3, so should do for IMAP and other server types too, but of course it is more complicated.

this is more serious for Win 10 than before at Win 7.
Win 10 downloads updates or reorganises files to make C drive exactly 0 bytes. Win 7 always left a few MB. After restart, Win 10 is back to 2GB, but that does not help, files are corrupted already.

If a warning is given to the user at full disk, he/she can free up space. For example, delete c:\windows\temp and c:\windows\logs, maybe even c:\users\<userid>\appdata\local\temp or delete something in downloads that can be recovered. Usually, some 10-200MB are sufficient to rescue TB if the msf has not been written already.

See Also: → 1169252

this is also related to the fact that TB cannot move large numbers of emails inside imap.

Even if I have a backup, I cannot get it back into the server. If I put backup into the imap mailfolder, it is deleted by TB.
If I put backup into local folder, I have to copy/move mails to imap, but that fails if large number of emails (>9000) - there is another bug for that.

So for the end user, both bugs are related. If this here happens and msf is deleted, even having a backup cannot help due to the other bug.

this is the bug on failing to copy large numbers of emails bug #538375.

You need to log in before you can comment on or make changes to this bug.