588006 - Renaming folders doesn't work, folder appears empty until restart

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Robert Kaiser]

Trying to rename a feed folder doesn't work correctly on SeaMonkey trunk, probably Thunderbird trunk as well.
The folder itself does rename, but the subscription and messages in it don't show up any more, and after a restart of the application, the folder is back to the old name.

This comes up on Error console (twice) when doing that rename:
Fehler: An error occurred updating the button_delete command: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIMsgDBView.hdrForFirstSelectedMessage]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: SelectedMessagesAreDeleted :: line 892"  data: no]
Quelldatei: chrome://global/content/globalOverlay.js
Zeile: 86

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

cf. bug 566704

Comment 2

[Jens Hatlak (:InvisibleSmiley)]

With the patch I just attached to bug 566704, the error message is gone (if the folder contains messages) but the actual problem persists, so the error message is just a symptom that doesn't really help fixing this bug.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

This affects Local Folders, too, not just feeds. Changing component to something more appropriate. Leaving in MailNews Core due to bug 606499 comment 1: confirmed with "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101022 Thunderbird/3.3a1pre"

Last OK: 2010-07-25
Broken since: 2010-07-26

Regression range: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2010-07-24+00%3A00%3A00&enddate=2010-07-25+23%3A59%3A59

-> Bug 377319 - Convert mailnews to frozen/external linkages

Pro Tip: Setting regressionwindow-wanted if the window is unknown helps getting things fixed (or at least draw some attention).

Seems like I cannot even *request* blocking-thunderbirdAnyDamnVersion. :-(

Raising Importance since to the user this looks like dataloss (although the folder is back for me after an application restart).

Comment 5

[[e-mail]]

Attachment: Proposed patch

The old code converted the hashed safe folder name from Unicode to platform encoding so it could pass the string off to nsILocalFile::MoveToNative. Since libxul doesn't provide an obvious conversion we simply switched to passing the original unicode strings to nsILocalFile::MoveTo which does the platform encoding for us. Unfortunately we failed to notice that we use the safeName again so it's not safe(!) to append .msf to it without using another temporary. I also removed the obsolete comment along the way.

Comment 6

[David :Bienvenu]

We're going to need some sort of unit test for this; I'll see if it can be an xpcshell test or if it needs to be a mozmill test.

Comment 7

[David :Bienvenu]

Attachment: unit test

add an xpcshell test for this

Comment 8

[[e-mail]]

Comment on attachment 504289 [details] [diff] [review]
Proposed patch

Pushed changeset 0c500ccf3988 to comm-central.

Comment 9

[[e-mail]]

Comment on attachment 505442 [details] [diff] [review]
unit test

Pushed changeset de1b3c4b08a6 to comm-central.