Closed Bug 490934 Opened 15 years ago Closed 15 years ago

With "remove immediately" delete model, entering any IMAP folder starts "compacting folder" process

Categories

(MailNews Core :: Networking: IMAP, defect, P2)

x86
Windows XP
defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: baffoni, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090430 Shredder/3.0b3pre

Every time I click on a new IMAP folder, the window status now reads "compacting folder", and looking at the files on the server, I'm seeing at least the cache and index files are being touched.

The end result is that it is taking at least 15-20 seconds to see new content in an IMAP window even if there is no change to the folder.  I think it is also causing much more load on the mail server just to display content in the new folder windows (but I have nothing objective to go by on this other than the observation of the index/cache files and general sluggishness of moving between folders).
Can you look into Tools > Account Settings > (account) > Server Settings which delete model you have chosen? Is it "When I delete a message:" > "Remove it immediately" or one of the other options?

If yes and you set it to "Just mark it as deleted", is the problem gone?
You are correct.  When I set it to "just mark it as deleted", it does not have this problem.  When I set it to either move to "trash", or delete immediately, it starts compacting everytime you visit a folder.  I take it this is a dupe of a known bug?
Actually, I was about to file this myself based on the observation I've stated
in bug 484445 comment #8, thus confirming this one here instead as this doesn't look right. The regression window fits and points down to that bug.

I'm only seeing this the first time I go into a folder not when I revisit it later (unless the IMAP connection for that folder has been shut down since).
Not using offline folders though, maybe that makes a difference.

Verified in current 20090430 Win32 nightly, IMAP log shows "expunge" is sent.
Blocks: 484445
Status: UNCONFIRMED → NEW
Component: General → Networking: IMAP
Ever confirmed: true
Keywords: regression
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Summary: Since at least 4/29, visiting any IMAP folder starts as "compacting folder" process → With "remove immediately" delete model, entering any IMAP folder starts "compacting folder" process
the design is that we issue an expunge if there are more than a certain number of messages with the deleted flag set, in both the trash and delete immediately modes, and never in the "mark it as deleted" mode. It looks like the check for the number of deleted message been broken so that we always expunge.
yeah, so this is not a good thing to do...I'll try to fix this.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b3
Attached patch proposed fix (obsolete) — Splinter Review
This gets us back to TB's original behavior, but should let Eudora do what it wants too.
Attachment #375417 - Flags: superreview?(bugzilla)
Attachment #375417 - Flags: review?(bugzilla)
I've reformatted this to be more understandable, and have the comment order match the code order. I don't think I've changed the functionality from the previous patch, but this should be clearer.
Attachment #375417 - Attachment is obsolete: true
Attachment #375811 - Flags: superreview?(bugzilla)
Attachment #375811 - Flags: review?(bugzilla)
Attachment #375417 - Flags: superreview?(bugzilla)
Attachment #375417 - Flags: review?(bugzilla)
marking p2 since this affects every imap folder select.
Priority: -- → P2
Whiteboard: [has patch for review, standard8]
Attachment #375811 - Flags: superreview?(bugzilla)
Attachment #375811 - Flags: superreview+
Attachment #375811 - Flags: review?(bugzilla)
Attachment #375811 - Flags: review+
Comment on attachment 375811 [details] [diff] [review]
make the comment match the code

My suggestion for indentation would be (relative to the if):

if (m_imapAction != nsIImapUrl::nsImapLiteSelectFolder &&
    (gExpungeOption == kAutoExpungeAlways ||
     (numDeleted >= gExpungeThreshold &&
      (gExpungeOption == kAutoExpungeOnThreshold ||
       (gExpungeOption == kAutoExpungeDeleteModel && !GetShowDeletedMessages())))))
  Expunge();

As that follows the emacs standard and each new bracket causes a one-space indent, so hopefully its recognizable that each line is one more bracket in from the previous.

r/sr=Standard8
fix checked in, with formatting fix.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [has patch for review, standard8]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: