Open Bug 188728 Opened 20 years ago Updated 6 years ago

'Compact Folders / C. f. when it will save over nn KB' and 'Get New Messages / Automatically download new messages' should never block one another

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

People

(Reporter: gabor.liptak, Assigned: bugmil.ebirol)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030109
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030109

it seems that compact folder and "automatically download new messages" do not
play well together.

Reproducible: Always

Steps to Reproduce:
1. Set "automatically download new messages" for your account.
2. (Optional) grow a giant inbox
3. Wait when a download new messsages triggers
4. Wait 10 - 0.5 minutes (just before the next download starts)
5. Starts compressing the Inbox folder

Actual Results:  
A message popups saying that I should not trigger a message download while
compressing the folder.

I wonder if messages were also lost? 

Expected Results:  
When folders are compressed, temporarily disable "automatically download new
messages"
i don't know if this is valid.
AFAIK this is only an info that autodownload can't work while compressing folders.
if autodownload cannot wokr, than disable autodownload until the folder
compression complete. I (the user) did no action and got an error message from
Mozilla ...
QA Contact: laurel → esther
*** Bug 189694 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212]


Following comment 3:

1) Bug confirmed on W95, with a case where it happens on Messenger startup.

2) Please, add a "s" to "folder" in the summary, to help find this report.


Reply to comment 2:

Another option would be not to disable "Get New Messages", but rather add a
dialog to say that it is delayed untill "Compact Folders" is completed...

See also bug 101584, as bug 188728 could be marked a duplicate of it,
considering that the discussion has gone "far" from its summary about the "alert
message" only.!.
My biggest gripe about this bug is that when the alert comes up the compacting
is suspended.  As a first step, I'd like to see one of two things:

1) Don't suspend compacting when the alert is displayed
  or 
2) Don't attempt to autodownload when compacting

The problem with the current behavior is that I'll start compacting when I'll be
away from my computer for awhile.  When I return, I expect the compacting to be
finished.  Instead I come back to find the alert displayed and the compacting
suspended.
There are bigger problems here.

If you have filter rules setup, when you pop open the mail client, it often
starts compacting and downloading simultaneously.  It gets part way through,
sometimes, and then says, mail not filtered because folder in use.

I agree with the original reporter that this is a really obnoxious bug, since it
keeps saying "Don't attemp to get messages, while compacting in progress", and I
did neither.  They just run on auto.
I can see these problems too. I agree that there should be no dialog and that
download should be automatically disabled during the compacting of folders.
After the compacting is complete automatic downloading should be reenabled
again. This would solve all problems with this bug including the filtering not
being able to move a message to the folder on which compacting is in progress.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 196452 has been marked as a duplicate of this bug. ***
Re: Comment#5

My experience of this is that the user is left totally confused about which
operation is proceeding and which is not:
1) On opening MailNews, or on spawning a new 3-pane view, up pops the invitation
"would you like to compact folders to save disk space."  Pretending to still be
innocent about such things I click "Yes."
2) Asynchronously, POP message download has been initiated; the status bar shows
"contacting [mailhost]" . . . "sending login information."
3) Conflict occurs (pretty much immediately), error message "Unable to download
because another operation is in progress."  Or sometimes a message citing a busy
folder.  Click OK.

Now - I know the answer by long experience but from the available information
what is my current state?

The download has been terminated - if one or two messages have been downloaded
they will likely get dropped into the inbox unfiltered, and very likely will be
duplicated (downloaded again) the next cycle.  BUT - the status bar says simply
"Done."

The compact is merrily ongoing.  But there is no obvious visible sign of it. 
And in my case I have such a damn big archive of old mail it may still be busy
the next auto-download period.

***
This is really, really, a DUPE of Bug#101584.  But that bug needs to be modified
so it addresses the conflict /behavior/ - not the awkward wording of the alert
messages.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312]

Bug still there.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Bug still there.
Is it so difficult to change so that, instead of triggering a suggested compact
operation upon entering a folder (including entering INBOX on startup), we do it
upon leaving the folder (including on shutdown).  That, at least, would
eliminate many of the most obnoxious occurrences.

Of course (d'uh) one could also set a global flag saying "one or more folders
are busy" while compacting, and simply defer downloading until the flag is clear.
Summary: compact folder and "automatically download new messages" → 'Compact Folders / C. f. when it will save over nn KB' and 'Get New Messages / Automatically download new messages' should never block one another
I get the alert about waiting until processing is finished even though I
do not have automatic compacting turned on in the preferences. I am using
Mac OS X 10.2.6 and a nightly build downloaded on 19 Jun 2003. Is it compacting
my Inbox even though I haven't told it to, or does compacting happen regardless
when you initially go to the Inbox? Am I supposed to just wait for compacting to
finish? Seeing messages that compacting is still in progress and has completed
would be extremely helpful. I had no idea this issue was related to compacting
until I found this bug report.
*** Bug 215511 has been marked as a duplicate of this bug. ***
taking, yeah, the time we do auto-compact is the worst possible time.
Assignee: sspitzer → bienvenu
Working much better in v1.4 but there is still a minor problem. If one accepts
the dialog window request to compact folders, and some messages are coming, or
just start to come, in, there is a message that Inbox can't be compacted, which
is okay, and it then proceeds to compact the Junk folder. But while messages are
coming in, some of them get marked as "junk", and because the Junk folder is
locked during compaction, they do not get moved to the Junk folder. After
compaction is complete, there are still some messages marked "junk" in the Inbox
which must then be manually moved to the Junk folder.

It would seem that in this scenario, the compaction routine should complete the
processes interrupted by its operation, such as moving the "junk" messages to
the Junk folder, then compacting the Inbox which had been previously skipped.
*** Bug 220423 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Now we do this after deleting a message, which is better than when entering a folder. For 3.0, we're going to try to do compaction automatically when the user is idle. Emre is working on that, so over to him.
Assignee: bienvenu → bugmil.ebirol
QA Contact: esther → message-display
I don't know how this bug got changed so that it contradicts its initial meaning, but as it has become, count me out.  Compaction and downloading messages are inherently incompatible actions and must always block one another.  Indeed, the cases where they try to happen at the same time always cause data loss.
You need to log in before you can comment on or make changes to this bug.