Closed Bug 518920 Opened 15 years ago Closed 14 years ago

Automatic compacting interferes with reading mail

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: rcoleman0, Unassigned)

References

(Depends on 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: version 2.0.0.23 (20090812)

I generally use Classic View with no Message Pane.

Given some messages in a folder, I double-click the first one to open and read it.  When finished reading, I click the Delete button at which time the next message in the folder opens.

I find that if I have the option "Compact folders when it will save over ..." active, sometimes the automatically triggered compaction will occur during the mail reading sequence described.  It seems that when this happens, the message being viewed cannot be deleted or moved.  It can be closed and re-opened at which point everything returns to normal.

Reproducible: Always




I left "Happens every time" selected under Reproducibility.

I assume it happens every time, but I don't actually know that.

I'm pretty well convinced that not being able to delete a message happens when automatically triggered compaction is effective and does not happen when that option is not in effect.
> It seems that when this happens, the message being viewed cannot be deleted or moved.

Does the mail appear in move target folder(Trash, if delete)?
How about "after rebuild-index of Trash folder"?
(Show "Order Received" column. It's offset in local mail folder file.)

If "delete/move while compaction is in progress at move source folder" case, and if bulk move(delete=bulk move to Trash), I think Bug 496892, Bug 498278, Bug 497804 etc. occurs.
"Remove from move source folder" step of delete of mail(==move from A to Trash=="copy from A to Trash"+"remove from A") silently fails if single mail move?
Or similar problem to Bug 495666 occurs when "delete of a mail while compatc in progress"?
Or "delete/move while compaction is in progress at move target folder" case?
Anyway, read Bug 498274 Comment #2 and check whether "while compaction is running" or not first.
"Does the mail appear in move target folder(Trash, if delete)?"

I'll have to check when this happens again.  I've never suspected this to be the case because the affected message always remains in the original folder and can be processed normally after being closed and re-opened, but I can't say for sure that there is not some time when the message appears in both the source and target folders.

It's not unreasonable to suspect that my observations are related to the bugs cited above, but the only symptom I've observed is not being able to alter the location of an open message which seems to be open or have been opened while automatic compaction is in progress.

I'll attempt to follow the steps in Bug 498274 Comment #2 and report back.
(In reply to comment #0)
> I double-click the first one to open and read it.
> When finished reading, I click the Delete button at which time the next message in the folder opens.

Did you execute above operation for multiple mails? Or single mail only?
If multiple mails, scenario may be;
(1) Delete a mail in a local mail folder, auto-compact is invoked
(2) During compaction next mail is opened in standalone window
(3) Compact ends, offset of mail of (2) is changed
(4) Delete for mail of (2) -> because offset is changed, delete does do nothing
Similar phenomenon can be seen on local Drafts folder. If compact is executed while editing of draft mail, previous version of draft is not removed upon next save, because offset is changed by Compact.

With Tb 3 nightly 2009/9/25 build, next phenomenon was observed.
(0) Disable auto-compact
(1) Move a mail to Trash, then move back to folder(to force compact)
(2) Double click other mail and open the mail in standalone window.
    (mail whose offset is changed by Compact. Show "Order Received" column)
(3) Compact
    -> Thread pane is changed to blank.
    -> Standalone mail window is closed.
What is Tb2's behaviour with above steps?
(In reply to comment #4)

 
> Did you execute above operation for multiple mails? Or single mail only?

Single mail only.


> 
> With Tb 3 nightly 2009/9/25 build, next phenomenon was observed.
> (0) Disable auto-compact
> (1) Move a mail to Trash, then move back to folder(to force compact)
> (2) Double click other mail and open the mail in standalone window.
>     (mail whose offset is changed by Compact. Show "Order Received" column)
> (3) Compact
>     -> Thread pane is changed to blank.
>     -> Standalone mail window is closed.
> What is Tb2's behaviour with above steps?

I don't think I understand this.  Why would moving a mail to Trash and back force compact after auto-compact has been disabled?
(In reply to comment #5)
> Why would moving a mail to Trash and back force compact after auto-compact has been disabled?

I wanted to say "Force compact execution of manual Compact at step (3)". If there is no deleted mail in a local mail folder, "Compact", "File/Compact Folders", and auto-compact does do nothing on the local mail folder, because there is no need to do compact.

> > Did you execute above operation for multiple mails? Or single mail only?
> Single mail only.

If "dialog before auto-compact" is enabled, and if the dialog is displayed by an operation of "delete a mail"(move to Trash), mail data of the mail is already written in Trash folder when the dialog appears, although the mail is still displayed at folder pane while the dialog is opened. I think delete of the mail itself is ended then the dialog is displayed.

If single mail only in your case, I guess next.
  1. You are viewing a mail in Inbox at standalone window
  2. auto-compact is invoked silently because you set mail.purge.ask=false,
     by mail move of filter, by mail purge of retention policy etc.
  3. Compaction is running on Inbox(and/or Trash).
     If mail folder file size is big and if you specified small threshould value,
     compact takes long. (If 1KB, almost all mails have to be copied.)
  4. Delete of a mail at standalone window
     -> Delete is not executed, or delete silently fails.

How long does manual compact take for Inbox in your environment?
How long does manual rebuild-index take for Inbox in your environment?
  1. Disable auto compact, move a mail to Trash and move back
  2. Context menu of folder, Compact
  3. Folder properties/Rebuild Index
Note: If rebuild-index is executed, "deleted mail count of the folder" is reset. So, step 1 is required to test "Compact" after rebuild-index.
(1) Original phenomenon of "Delete at stand alone window doesn't work" is reproduced with Tb 2.0.0.23.
  1. Show "order receieved" column,
     move smallest offset mail in Inbox to Trash, and move back.
  2. Empty Trash. Compact Trash
  3. Open smallest offset mail(initially 2nd mail) in stand alone window
  4. Compact Inbox
  5. After end of compaction, delete at standalone window
     -> mail is not deleted from thread pane
This is similar(nearly same) phenomenon as next.
  If compact is executed while editing of draft mail, previous version of draft
  is not removed upon next save, because offset is changed by Compact.

(2) If "dlete at standalone window" is executed while compact is in progress, alert was issued.
  1. Show "order receieved" column,
     move smallest offset mail in Inbox to Trash, and move back.
  2. Empty Trash. Compact Trash
  3. Open smallest offset mail(initially 2nd mail) in stand alone window
  4. Compact Inbox
  5. While compact is running on Inbox, delete at standalone window
     -> Next alert. Mail is copied to Trash.
        If delete is repeated, same alter can be observed, and number of copy
        in Trash increases.
> Alert
>   !  Unable to delete messages in folder xxx because it is in use by some other
>      operations. Please wait for that operation to finish and the try agin.
>                              [ OK ]      -> mail is not deleted from thread pane
This is same issue as Bug 496892 and/or Bug 498278.

(3) If Tb3.0x nightly build, problem of Comment #4 occurs. So above two phenomena can't be observed with standalone window + compact.
FYI.
Next phenomenon(met during test for Bug 482836) is written in Bug 482836 Comment #5.
  If compact is executed while editing of draft mail, previous version of draft
  is not removed upon next save, because offset is changed by Compact.
I'm having some trouble following all of the above.

Do I correctly interpret the above comments as confirmation of what I reported and that no additional information is required from me?
(In reply to comment #9)
I can say nothing about phenomenon/problem really occurred on you.
I can say next only by my test results.
  (a) If compact was executed(and ended) while you are viewing mail at standalone
  window, and (b) if the mail's offset in local mail folder file was changed by
  compact, phenomenon you described in comment #0 can happen with Tb 2.0.0.23.
  (Note: if mail of largest offset only is deleted and compacted,)
  (      offset of any mail is not changed by compact.           )
There is still no evidence of (a) and (b).
Check with "mail.purge.ask=true + Cancel reply to dialog" in daily use, please.
Because no alert occurs upon delete in your case, there is no need to check compact/rebuild-index time etc. any more.
(In reply to comment #10)

OK, I just had two mails in Inbox.  I double-clicked the first.  It opened in new window.  I read it and then clicked Delete button in toolbar to delete it.  I received dialog as a result of "mail.purge.ask=true".  I clicked Cancel.  Mail was properly deleted (moved to Trash) and second mail opened automatically.

I think, but can't prove, that if "mail.purge.ask=false" had been in effect, mail being viewed would have become "stuck" (not able to be deleted).

The next time I get the dialog, I'll click the option to allow compaction to occur and see what happens.
Version: unspecified → 2.0
I just got the dialog from "mail.purge.ask=true" again.  This time, I clicked OK instead of Cancel.  The result was the same as I had observed before setting "mail.purge.ask=true".  The mail I was viewing could not be deleted, but could be closed. 

After closing, I checked and found the mail still in the inbox, but not in the Trash.  I then opened and deleted the mail and continued normally.

I'm only guessing now, but it sort of seems that the deletion proceeds far enough to trigger automatic compaction, but not far enough to actually delete the mail.
I just attempted to delete a mail and got the dialog from "mail.purge.ask=true"  and clicked OK.  This time the mail was deleted and the next one opened, but that next one could not then be deleted without first being closed.
FYI.
Bug 458335 has been DUPed to Bug 224825.
I've opened Bug 520115 for problem of comment #4 on Shredder.
This problem, at least the symptoms I originally reported, seems to be fixed in
Thunderbird 3.

Well, the above is what I intended to put here on 2009-12-30, but accidentally put somewhere else.

I'm no longer sure the comment is adequate though.  What I now believe to be the case is that the Thunderbird 3 behavior is better, but not ideal.  

I now think that, in Thunderbird 3, the message the disposition of which triggers compaction is properly disposed of (moved/deleted), but the next message is not automatically opened as it would be if compaction had not been triggered.

I have to observe some more to be completely confident that this is the case though.
xref to Bug 520115 for ease of tracking.
Bug 520115 looks to have been resolved by Tb 3.1(fixed by Bug 536676).
Depends on: 520115
WFM per comment 16, I think. Please clarify the exact issue that you see in version 3.1 if that is incorrect
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.