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.

confirmed by Susanne Jäger in d.c.s.m.mailnews on Linux too, switching to "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?

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.

Relnoted, see bug 656719 comment 30.

Removing relnote keyword since this doesn't happen anymore by default since SM 2.2.

(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