398151 - compact failed when Disk is full - 2 months of email lost (NFS mounted partition without the lock deamon)

Status: UNCONFIRMED

(MailNews Core :: Backend, defect)

Description

[Tim Bevan]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1) Gecko/20061023 SUSE/2.0-30 Firefox/2.0
Build Identifier: version 2.0.0.6 (20070728)

The disk was full, Thunderbird crashed. I cleared some email, got rid of other files off the disk. This might not have been enough space cleared. Tried to compress; thunderbird crashed again. Looks like the Inbox was truncated to late July. 

I have had the Inbox restored from the last backup, so only lost todays emails, but this is still worrying. 

Reproducible: Didn't try

Steps to Reproduce:
1.
2.
3.


Expected Results:  
Ideally the software would report that it was unable to do the compression, clean up and leave the original mailbox intact.

NB this is an NFS mounted partition without the lock deamon. This should not have any effect as there is only one process trying to access the email.

Comment 1

[Jo Hermans]

I though that the compressed data was written in a temporary file (called "nstmp"), so the original data should be safe.

Comment 2

[Wayne Mery (:wsmwk)]

I think this should be gone in version 3.1, perhaps even in 3.0. I no longer remember the details

Comment 3

[Thommie Rother]

a full disk is always bad for software activity. no special suse issue and no activity for a long time, please close

Comment 4

[Thommie Rother]

Tim, can you please test this on opensuse 11.4 with latest TB 3.1.8

Comment 5

[Wayne Mery (:wsmwk)]

we don't normally confirm bugs that don't have independent confirmation of being valid in a current release or trunk build, and/or do not have enough information for a developer to reproduce and fix

Comment 6

[Andrew]

You also do not normally bother to look at the code. Instead you normally ask users to test the faults.

Was it so difficult to see why compaction destroys data?

I suspect the issue here arises from another bug, which I just solved there:
https://bugzilla.mozilla.org/show_bug.cgi?id=674742#c23

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Andrew from comment #6)
> You also do not normally bother to look at the code. Instead you normally
> ask users to test the faults.

people who don't code will tend to do that :)
we do our best to help, as best we can.

Anyway, I'm not convinced the problem still exists, because I thought there was a patch for it (as hinted in comment 2). But I also have not tested it - and don't currently have a machine I care to attempt it.


> Was it so difficult to see why compaction destroys data?
> I suspect the issue here arises from another bug, which I just solved there:
> bug 674742 comment 23

Andrew, does your solution in bug 674742 comment 23 extend to cases where data has not been encrypted?

Comment 8

[Andrew]

Do you mean you do not code? And nobody else does? Then why report a bug at all? And why people subscribe to the bugs, and discuss them?

Yes. The bug 674742 does affect all data, on all systems.
It actually consists of at least 2 bugs. It has 1 body, and 2 heads. New heads can grow, and perhaps have grown.

In an attachment there I do mention that the bug is not restricted to encryption.
It is simply waiting for any error a programmer or an operating system might make.
The bug of encryption is just one pathway for the bug to work. It simply triggers the bug of destruction. There can be any other triggers, many ways. - Many heads of the bug.

Perhaps a "trigger" is in action also in this bug, which we are writing in.
Compaction failed at some stage. Then it detected an error, and deleted the data. Eventually it crashed.

The signal for destruction of data propagates through return codes of functions. Many intermediate calls are made. Each requires a check for bugs.

I am not sure that any patch, which you mention, has removed this bug. Especially that you do not show any patch.

Hence, a trigger for bug 674742 may still be there.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Andrew from comment #8)
> Do you mean you do not code? 

In referring to prior comments 1-5 you set the context in comment 6, by saying "You also do not normally bother to look at the code. Instead you normally ask users to test the faults."  So again, YES, there are many people here who do not code.

> And nobody else does? Then why report a bug at all? And why people subscribe to the bugs, and discuss them?

Of course there are people who code. 


> I am not sure that any patch, which you mention, has removed this bug. Especially that you do not show any patch.

My point is, it might have been fixed in a different bug report. I guess we will know if it is fixed or not when someone tests the steps for this bug  :)

> Hence, a trigger for bug 674742 may still be there.
so let's assume until proven otherwise that your proposals in bug 674742 will help here.

Comment 10

[Wayne Mery (:wsmwk)]

I hope this is fixed by bug 674742 but it should also be noted that this bug predates the time frame of the regression bug ("delivered in TB5 time frame) which prompted bug 674742.

bug 797215 may be a duplicate

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #10)
> I hope this is fixed by bug 674742 

fixed October 2012, Thunderbird 18.  But that is not nfs.

The pop download case would have been fixed by bug 239455 in tb26 circa Sept 2013