Open Bug 324576 Opened 16 years ago Updated 3 years ago

Go offline, to prevent dataloss that can happen if mail come in while compacting a large folder

Categories

(MailNews Core :: Backend, defect)

defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: tveazey, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Thunderbird 1.5 (20051201)

It seems to be a well-documented and well-known fact that interrupting TBird while it is compacting folders creates an "nstmp-XXX" file; I've seen this sometimes double the size of a profile folder.  One source of interruption I've seen pointed to by many different people is receiving mail. Thus they recommend first taking TBird offline, then compacting, then going back online (see the MozillaZine KB article http://kb.mozillazine.org/Nstmp_folders); however, this is non-intuitive/non-trivial for the average user. I suggest tweaking "File > Compact Folders" to temporarily take TBird offline until the compaction is complete, then return it to the online state.

Reproducible: Sometimes
I oppose this change unless it is made optional for the user.  Yes, compacting folders does hinder other actions you might want to do involving those folders, but there's no reason I shouldn't be able to compact my mail folders while reading Usenet news or blogs.

A better fix for this annoyance would be to have automatic compaction occur on exit from TB, rather than at startup.
Every time I launch TBird it flashes a query at me, asking if I want to compact all folders - while it is downloading the new mail. This makes no sense to me. I think it should wait until it has finished downloading.
in 2.0, we'll only offer to compact folders after you delete messages, not while downloading headers.
I find it peculiar that this known bug (now over two years old) still has an "unconfirmed" status.

While I had not thought of it, Mr. Galt's objection is valid.  While most people would not have his problem, it certainly is not a good idea to be creating a new problem (even if arguably for "only" a few people) to fix another (that might appear to be the "greater" problem).  Is there not some other way - other than taking TB totally offline - to suspend/block downloading of emails (without affecting news/blogs)?  It would seem to be a trivial thing to do, but I am not a programer, so it's easy for me to say.

If it is not practical to disable other email account activity while compacting without going completely offline, perhaps Mr. Galt's suggestion in his first sentence is the best answer - make it a user option.  It would be reasonable to set the default to be to go offline before compacting since that would be the "solution" for the most (typical?) users.
No, for the 99%+ of users, it would only be annoying.
99%?  Not credible.  It means that you can't have automatic periodic downloads and automatic regular compacting from an extension like Xpunge - choose one or the other, but not both. Also means you have to manually go offline before compacting if you have automatic periodic downloads and then manually go back on line.
I'm not sure why building in a safeguard to prevent a program from screwing up the email by trying to simultaneously download and compact would be annoying.  You've got to be kidding.  I'll empty my cat's litter box, but it darn well better not be trying to take a **** in it when I'm in the process of doing so.  I see this as similar.

If it really would be annoying to prevent mail downloading during compacting (again - I fail to see why that is annoying), then take Mr. Galt's suggestion to make it optional, but set the default to allow simultaneous compacting and downloading and screwing up your email (if that's what people really want - which I find extremely hard to believe, but whatever).
Of course it should prevent errors/problems, but going offline it's a good option imo.
Assignee: mscott → nobody
it's -> isn't 
Fair enough.  But that's why I said "Is there not some other way - other than taking TB totally offline - to suspend/block downloading of emails (without affecting news/blogs)?."

Perhaps, then, we would agree that what is needed is a new bug report to replace this one that proposes to prevent downloading of emails (of user selected accounts?) - IOW, stopping short of going totally offline so that ng/blog activity is not interfered with.  Would that address all concerns?  (There remains the programing question of how to prevent downloading on a given account without simply taking everything offline - that's a feasibility question for the programers.)

[modifying the summary]
I think we should investigate this for tb3.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Backend
Ever confirmed: true
Flags: blocking-thunderbird3?
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: general → backend
Hardware: PC → All
Summary: Compact Folders should take TBird temporarily offline → prevent dataloss that can happen if mail come in while compacting a large folder
Severity: enhancement → major
Product: Core → MailNews Core
(In reply to comment #11)
> [modifying the summary]
> I think we should investigate this for tb3.

Triaging according to new policy for flags.  
https://wiki.mozilla.org/Thunderbird:Release_Driving

Setting wanted+ because we need to investigate this. Assigning to David as I think he'd be the best to look at it.
Assignee: nobody → bienvenu
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Keywords: dataloss
Priority: -- → P3
Target Milestone: --- → Thunderbird 3.0rc1
Depends on: 479285
Assignee: dbienvenu → nobody
Summary: prevent dataloss that can happen if mail come in while compacting a large folder → Go offline, to prevent dataloss that can happen if mail come in while compacting a large folder
Target Milestone: Thunderbird 3.0rc1 → ---
Bug 439089 - Auto compact on idle time with better threshold - should go a long way to preventing this.  WHich should include NOT compacting during startup or any time near it.

Beyond that, it seems to me we should just prevent the dataloss straight off. AFAIK this mainly involves filters eg bug 274330
and bug 139215
Priority: P3 → --
See Also: → 439089, 274330, 139215
You need to log in before you can comment on or make changes to this bug.