User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1) Gecko/20061022 SeaMonkey/1.1b Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1) Gecko/20061022 SeaMonkey/1.1b Saving an email message as a file fails. Reproducible: Always Steps to Reproduce: 1. Select an email message. 2. Right click on it and save it as a file. 3. Check to see if the file is there -- it won't be in my case. Actual Results: No file is produced. Expected Results: A file should be created.
I should add that this was present in the 1.1 alphas for at least a couple of months.
Do you see any error in the Error Console under Tools->Web Development while/after saving to a file? Do you know if this works in SeaMonkey 1.0.x?
(In reply to comment #2) > Do you see any error in the Error Console under Tools->Web Development > while/after saving to a file? Do you know if this works in SeaMonkey 1.0.x? > I see no errors there, and yes, it does work fine in Seamonkey 1.0.5.
Confirmed in Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1) Gecko/20061024 SeaMonkey/1.1b (self-compiled)
I had been building using GTK1. I rebuilt last night using GTK2 (an interesting process under Solaris 8), and the problem persists.
OK, I've just done some more testing. Actually, saving local messages (POP or localo folders) works, but saving messages from IMAP or NNTP (news) doesn't work. Adjusting summary to reflect that. Karsten, Neil, could someone familiar with MailNews and/or file saving look into that?
Just to clarify: File picker comes up as usual, no message in error (JS) console, but no file showing up on disk. And it's independent of using context or "File" menu entries for "Save as", it always the same. As I already stated, POP/local messages work fine.
I don't see this with a recent Tpol Windows branch nightly, but I can confirm it under MacOS X...
I can confirm that both trunk and branch Windows save IMAP messages, while my trunk Linux build does not (I have no branch Linux build).
This regressed between linux seamonkey builds 2006-05-19-09-trunk and 2006-05-20-08-trunk, probably bug 328027
I did (because I didn't look here :|) my own regression window search on Mac-1.8-branch and get 2006-05-21-13 okay, while 2006-05-23-17 is broken (no other builds are available on ftp.m.o). And I, too, found bug 328027 as the most likely suspect in that window, especially since some debugging I did earlier did indeed touch the very functions changed there...
Created attachment 244005 [details] [diff] [review] Close any streams before deleting the target file So, the problem is this: In nsMessenger::SaveAs we create a nsSaveMsgListener, which (due to bug 328027) automatically opens the stream on the nsIFileSpec object, creating an empty file. But the actual save operation for IMAP and NNTP is done by a nsMsgSaveAsListener, which first deletes any such file - but the stream is still open and all data goes to nirvana... This patch is against 1.8 branch, but applies to trunk as well.
Comment on attachment 244005 [details] [diff] [review] Close any streams before deleting the target file nice work, Karsten, thx for fixing this. Can you add a comment to the code, just like your last comment in the bug?
Landed on trunk, but we _really_ should get this into the 1.8 branch soon!
You need to set the relnote keyword if you want a relnote. I did not find this in any of my queries.
FYI: with TB 2b1-1026, Win2K, I have no problems saving messages (as .EML) from IMAP or NNTP. Is there some additional step to reproduce not listed in comment 0?
it only seems to be a problem on linux and mac. Anyway, I'll land this for 2.0 - it should be marked fixed, since it's fixed on the trunk.
fixed on branch, removing relnote keyword, not sure why we'd need that anymore.
Comment on attachment 244005 [details] [diff] [review] Close any streams before deleting the target file Clearing approval flags, it's already on the branch...
verified fixed 22.214.171.124 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199) Gecko/20070326 Thunderbird/188.8.131.52 Mnenhy/0.7.5.0 ID:2007032620 using my imap account and my nntp account.