Closed Bug 790965 Opened 13 years ago Closed 12 years ago

thundebird loss of data (inbox emails) after killing TB (CRITICAL)

Categories

(Thunderbird :: General, defect)

15 Branch
x86_64
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: firefox, Unassigned)

Details

(Keywords: dataloss, perf, Whiteboard: [dupeme?])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 Build ID: 20120907231657 Steps to reproduce: thunderbird was slowing down whole computer and jamming SSD disk drive (SSD disk LED constantly on, haven't seen this before, LED just blinks for all other apps) computer unresponsive, so i killed thunderbird (X kill) Actual results: some emails were showing as blank after TB restart e.g. no from, no to: fields, no content after deletion of Inbox.msf, emails of past approx. 10 months completely lost/deleted i had to redownload at least past few hundred emails that have been kept on server for few days Expected results: no loss
Severity: normal → critical
pop or imap? did you ever experience slowness when using 15.0 or 14.0? Please post your addons from helpl | troubleshooting
Maybe it was compacting the folders? But cutting that in the middle should have preserved the original uncompacted files. Wayne, looks like POP as only the last message were kept on server. Daniel, it is never good to kill a program that is currently working with files on disk. You'll get corruption in any program. It only depends how valuable are the files that get corrupted. In TB's case they are very much. But when TB is compacting then it tries to do it safely, like making a copy of the folder and only replace the original once the work is finished.
:aceman - I know, but I wasn't sure what was actually jamming SSD disk as Thunderbird wasn't really showing that much activity in "top". The loss here is not that tragic - most of the emails I have replied to, so I have copies kept in the Sent folder. But as far as I remember, TB was always keeping temporary file when compacting, has this been changed? I have not found any temp files after this.
Yes, I said Tb should make a temp file (copy) of the folder. You can also sometimes see in Tools->Activity manager if TB is doing some long operation (like compacting or indexing folders).
aceman, good point that Activity manager, I will be checking that next time, thanks.
Keywords: dataloss
Whiteboard: [dupeme?]
(In reply to Daniel from comment #3) > But as far as I remember, TB was always keeping temporary file when compacting, > has this been changed? I have not found any temp files after this. (Case-A) A whole exists in Compact. Compact roughly consists of; (1) from original/original.msf, create compacted version of nstmp/nstmp.msf. (2-a) rename nstmp to original with replace mode. (if Win, MoveFileExW with replace mode) (2-b) rename nstmp.msf to original.msf with replace mode. As written in bug 498814 comment #28, if error is somehow returned to rename at step (2-a), Tb currently may delete both origial and nstmp. (Case-B) Further, if power failure/system crash etc. occurs just while OS is executing request of "rename AAA to BBB with replace mode", both AAA and BBB may be deleted. As seen in depenency tree for meta Bug 193638(prefs.js loss is reported even after SafeFileWriting is used for prefs.js). SafeFileWriting in prefs.js is; write new version to prefs-N.js, then rename prefs-N.js to prefs.js with replace mode. Even though this logic, loss of prefs.js was actually occurred. Because "rename of a file" is "modify of many data blocks of directory entry", power failure at mid of the directory data update can produce file loss. Step (2-a) of Compact is same as this SafeFileWriting of prefs.js, so loss of original & nstmp can occur. In your case, if Compact was running when your SSD disk trouble happened, both (Case-A) and (Case-B) might occur.
FYI. prefs.js loss I actually saw once. 1. Force Tb's high memory usage and high CPU usage (e.g. select many many mails + Mark As Junk) => Tb became unresponsive. OS also became unresponsive with heavy swapping. 2. Try to kill Tb and OS => Uable to termiate Tb, unable to terminate OS. 3. Force power off by "Power Key". 4. Upon power-on & re-boot of Win-XP, CHKDSK was invoked, and removel of prefs.js was reported because entries for prefs.js was incomplete in file system. 5. prefs-N.js was not kept. So, I can't imagine other than incomplete "rename prefs-N.js to prefs.js".
wada, but he was only missing some emails. not a whole folder. and not prefs. and... this is linux
Daniel, do you see this problem if automatic compact is disabled?
Flags: needinfo?(firefox)
Keywords: perf
Hello, I think since then it works better by saving it to .tmp folder. I haven't sinced encountered such situation, but I try not to kill it now whenever it blocks CPU...
Flags: needinfo?(firefox)
(In reply to Daniel from comment #10) > I haven't sinced encountered such situation, In that case let's closed the bug. Please file a new bug if you see a different problem. > but I try not to kill it now whenever it blocks CPU... If you have super high CPU on compact then you should be looking at antivirus or something else to be causing the high CPU. > I think since then it works better by saving it to .tmp folder. I have no idea what this means for what you might have changed.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.