Closed Bug 660845 Opened 13 years ago Closed 8 years ago

Archives folder rendered inaccessible after archiving a news posting

Categories

(SeaMonkey :: MailNews: Backend, defect)

SeaMonkey 2.1 Branch
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1166225

People

(Reporter: stefan.blumenrath, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Lightning/1.1a1pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1

Using the archive-function on news, the actual archive folder (i.e. archive-2011) won't load till restart.

Reproducible: Always

Steps to Reproduce:
1. Archivate a mail, so that the archive folder exists
2. switch to a news-posting
3. press 'a' or try context-menu "archivate" ('archivieren' in German)
4. try to open the achive folder

Actual Results:  
the folder opens blank, windows sandclock won' stop. All archieved mails seem to be disappeared. The files 2011 and 2011.msf are full with the data. After a restart, the problem disappears.

Expected Results:  
open the folder with content

in the .msf are two blank entrys after the last added message, I didn' find this after adding a mail.
Confirmed with SM2.1RC, setting version accordingly, trunk untested (yet).

Archiving a mail is not necessary to reproduce, the default settings save archived messages to the local archive folders, which is being created instantly when archiving a news posting.

With sandclock he's refering to the hourglass, note that it is only visible while the mouse cursor is in the folder-pane. Folder won't open/show it's contents as descibed.

There is no error in the error-console.
Severity: major → blocker
Status: UNCONFIRMED → NEW
Component: MailNews: General → MailNews: Backend
Ever confirmed: true
QA Contact: mail → mailnews-backend
Version: unspecified → SeaMonkey 2.1 Branch
confirmed by Susanne Jäger in d.c.s.m.mailnews on Linux too, switching to "all".
OS: Windows XP → All
Hardware: Other → All
OK, I can reproduce the error, bur the re-appearance of the folder after restart is NOT reproducable. I attached a file with the entrys to the 2011.msf after trying to archive. It looks at last very different compared to formerly archived mails.
Confirming using the STR from commment 0 (BTW it's Shift+A in SM); adjusting summary to be more exact. No messages on the Error Console (neither when archiving nor when accessing the Archives folder). Either this is a back-end problem or an issue with the glue code that calls the back-end. I never tried archiving a news posting before, so maybe we need to special-case something.

Is this a regression, i.e. did it happen with SM 2.0, too? Or older (pre-release) versions of SM 2.1?
Summary: When trying to archieve a NEWS-Posting, the archive-folder gets temporaly compromised → Archives folder rendered inaccessible after archiving a news posting
Also it would be interesting how different versions of Thunderbird behave in this case, since they share the back-end with us and use almost the same glue code.
AFAICS the same happens if you do a move d&d of a news posting to a local folder. This is not surprising because the actual copy method called is the same (gCopyService.CopyMessages) and the decision whether a copy or move is attempted depends on srcFolder.canDeleteMessages for the Archive feature:

http://mxr.mozilla.org/comm-central/source/suite/mailnews/mailWindowOverlay.js#1335

canDeleteMessages for news folders depends on nsMsgNewsFolder::GetCanDeleteMessages which returns (AFAICS):
* always FALSE for comm-1.9.1 (SM 2.0)
* always TRUE (from nsMsgDBFolder::GetCanDeleteMessages) for comm-2.0 (SM 2.1)
* the value of pref news.allow_delete_with_no_undo (default = FALSE) for comm-central, comm-aurora and comm-beta (SM 2.2 and later)

I haven't checked comm-miramar (TB's release branch) but AFAIK they adopted the pref-based behavior. This means that there probably isn't any TB release that shows the same issue by default.

In other words, this will "fix" itself for SM 2.2, as long as you don't toggle the news.allow_delete_with_no_undo pref to TRUE. For SM 2.1, there is no workaround unfortunately (other than patching the code to special-case news or return FALSE in nsMsgNewsFolder::GetCanDeleteMessages).


If this gets fixed in the back-end, fine (maybe this needs to be moved to MailNews/Core then). Otherwise we need to check what else (other than archiving and d&d) is affected.
(In reply to comment #4)
> Is this a regression, i.e. did it happen with SM 2.0, too? Or older
> (pre-release) versions of SM 2.1?

Happens in SM2.0, too.
Removing relnote keyword since this doesn't happen anymore by default since SM 2.2.
Keywords: relnote
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #5)
> Also it would be interesting how different versions of Thunderbird behave in
> this case, since they share the back-end with us and use almost the same
> glue code.

This does not reproduce for me in thunderbird daily
this is bug 1166225
Severity: blocker → major
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.