313147 - offline news folders are not compacted if db is out of sync with offline store

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Virgo Pärna]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Thunderbird version 1.5 Beta 1 (20050908)

I'm using Thunderbird as my news reader for offline reading with Delete messages
more than [30] days old. "Compact folders when it will save over [100 kB]" set.
When this autocompacting is triggered, then large (over 4 MB) offline news
folders are not compacted. I have watched what happens - when compacting folders
nstmp file is created, it starts growing, then it disappers (status bar in
Thunderbird shows, that next folder is compacted), reappears and starts again
growing. But when it reaches to large forlder, nstmp is created and  then
nothing happens. I have tried waiting   for several hours, nothing happens. And
sometimes autocomacting is triggered again and it says, that it cannot compact
this large folder, because it's in use. And if Thunderbird is closed and then
executed again and it tries to compact folders, nstmp-1 file is created and it
stays 0 size.

Reproducible: Always

Comment 1

[David :Bienvenu]

None of the large offline news folders are compacted? Or is it just that it gets
stalled on a particular one, and never gets to the next one(s)? You're saying
that the nstmp file does not grow at all when it gets to the problem news
folder? You could zip up the .msf file and the offline store for the newsgroup
in question and e-mail it to me, and I can look at it.

Comment 2

[Virgo Pärna]

Just specific folder does not compact. And it has happened with another folder
do - then I just deleted msf and data file. But now it happened again. I'll mail
the files David. Just a thought - could mnenhy (not working in 1.5) be cause?

Comment 3

[David :Bienvenu]

unlikely, but you could look at the javascript console (tools | javascript
console) while the compact is going on and see if anything shows up.

Comment 4

[David :Bienvenu]

OK, I see the problem with those test files. thx. I'll debug it.

Comment 5

[David :Bienvenu]

Thx for the test case. The basic problem was that your offline store and the
.msf file were out of sync with each other, for some reason, and that was
causing the compaction process to spin.

Comment 6

[David :Bienvenu]

oh, so, I meant to say, Virgo, that you might as well just delete those two
files from your user profile. The .msf file will get regenerated (all the
headers will get redownloaded) and then you can redownload for offline use the
messages in that newsgroup.

Comment 7

[David :Bienvenu]

Attachment: handle case where offline store and .msf file are out of sync better

If the offline store is out of sync with the .msf file, we weren't falling back
to  getting the message from the server. We were trying to do so, but
nsNNTPProtocol was only half initialized, because ::Initialize bails out early
if it thinks we have the message offlne. So this fix does a few things:

If we discover that we don't actually have the message offline because we
failed to create the stream on the offline store, clear the flag on the msg in
the db.

Similarly, clear the flag on the url that says we have the msg offline.

When trying to read from the nntp connection, detect a partially initialized
protocol object and recall Initialize - Initialize is smart enough to do the
right thing in that situation.