Using oct16 mn6 branch commercial build linux rh6.0, Win98 and mac OS 9.0 "Unknown error" occurs when selecting a message which was a Drag & Drop from newsgroup to POP folder. 1. Profile has both POP account and newsgroup account. You've logged in for the pop account. 2. Open newsgroup, select a message and Drag&Drop it to a folder on the POP account (Inbox or user created folder, top level or sublevel). 3. Go to the destination folder on the POP account and select the message you just dragged from the newsgroup. Result: Upon selecting the message Unknown Error alert appears. Upon OK to the alert, the message body loads, all is ok. Expected: No alert. Note: This doesn't happen when using the menu item Message|Move or Message|Copy, but I have noticed that the menu item will sometimes fail (on Mac) and there will be no header in the destination folder.
I've been repeating this scenario and found this to be more damaging than it appears at first: -- the message doesn't always load after getting the unknown error alert, sometimes it does and sometimes it doesn't. -- after you've received the "unknown" alert, subsequent copies via Menu item Move or Copy will not reflect in that same destination folder. That folder will no longer accept moves or copies from IMAP, News or assuming POP. David: might this be related/similar to bug 56007 or its fix?
Laurel, no, it can't be related.
*** Bug 56909 has been marked as a duplicate of this bug. ***
*** Bug 56910 has been marked as a duplicate of this bug. ***
Adding relnoteRTM keyword. OK, after further testing on Win98 (will try again with Mac to confirm), it appears that even when the folder is in its weird state of not accepting any moves/copies we do not have a case of true data loss. 1. When in the bad state, if it's a POP Inbox, it still gets new messages and you can select them, bodies download. 2. When in the bad state, if a Move Message happens from any other source to that folder, the message doesn't really move; the move fails and the message stays in the source/originating folder. 3. When in the bad state, if it's a POP folder which gets a message filtered to it from the Inbox on the same account, the filter fails and the message stays in the Inbox. 4. Like I mentioned, after exit the folder seems to regain its normal qualities. 5. To reiterate, using menu items to copy/move DOES work from news to pop until such time as you've D&D from news to pop. 6. Downside is that a user who does copying to a POP folder in this state will not wind up with the copies of the data -- the copies do not ever make it to the folder, even after restart. 7. But the good news is a copy is only a copy, and unless the user deletes the source mail message in the meantime, they can always do another copy. In the case of the news copy, it is likely the news message will be around to re-copy. 8. This doesn't happen with POP-->POP D&D, IMAP->IMAP D&D, IMAP-->POP D&D, or News-->IMAP D&D.
nominate for 6.5 fix.
marking nsbeta1+ and moving to mozilla0.8
reassigning to sspitzer
I logged a dup of this. let me re-assign to chuang and then go mark my bug a dup. I feel this is a p1. the folder is corrupt. great catch laurel.
*** Bug 64366 has been marked as a duplicate of this bug. ***
I believe this is a backend (CopyMessages) problem. The message is dropped correctly in the folder. Reassign to Navin.
the news msg is correctly copied to the local folder, but the db hdr for the msg in the local folder is incorrect, either in msg position in the folder, or size, or both.
I have one line fix for moving/copying one message. Basically the copyState was not getting cleared and the notification that copy is over was not being sent.
sr=mscott on the patch navin emailed me
fix checked in.
naving - can you take a look at bug 65029.
OK using jan11 commercial trunk builds, linux rh6.0, mac OS 9.0, win98. Tested single and multiple selection D&D news-->local/POP folder. Did not retest other news copying methods -- sheelar can cover that when she does her move/file/copy testing.