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  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
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.
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?
OK, I see the problem with those test files. thx. I'll debug it.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Summary: Large offline news folders are not compacted → offline news folders are not compacted if db is out of sync with offline store
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.
Created attachment 200273 [details] [diff] [review] 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.
Attachment #200273 - Flags: superreview?(mscott) → superreview+
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.