Closed Bug 57902 Opened 21 years ago Closed 21 years ago
"Send Page" fails to forward the included page - out of disk space
build: 2000-10-23-09-MN6 1. GO visit a page: http://www.mozilla.org/projects/l10n/mlp_distrib.html 2. "File|Send Page" 3. To: yourself 4. "Send" 5. You will get a dialog saying that the "sent" operation succeeded but "copy to Sent folder failed..." dialog. 6. Either "OK" or "Cancel" to dismiss the dialog The mail arrives with no "subject" line nor message body or forwarded page...
Ahh..., I know what went wrong.. My local disk is running out of disk space. 4.x gives warning about failing to write to disk file; Mozilla does not...
ah! we have all sorts of bug reports on out of disk space :-) We don't give a warning right now.
Summary: "Send Page" fails to forward the included page → "Send Page" fails to forward the included page - out of disk space
Related (disk space) bugs: bug 55814, bug 49868, bug 32443 Will include as part of general out of disk space relnote
QA Contact: esther → laurel
Another low disk space bug is the FTP download bug 82478
Adding nsenterprise+. I'm curious to know how hard this would be. I'm cc'ing ducarroz (feel free to reassign).
over to Jean-Francois & varada.
Assignee: mscott → ducarroz
this work will happen during .9.5 but is still scheduled to land on the branch.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
per comments changing to ASSIGNED
Status: NEW → ASSIGNED
what's the status on this? Are we close to a fix? Marking nsenterprise- to get it off the stop ship radar. Will consider fix if we get one in the next few days.
I don't have a status. I haven't looked at it yet!
I did some test with a recent build and when my disk is full and It try to send a message with or without an attachment, I get a error message telling you to check your temp folder. The message is not send. Reporter, can you test that again with a recent build.
My previous test was bogus as in fact I had the wrong patch to the temp folder setup in my environment. I did more testing with varios case of failure due to low disk space and either we report "Sendin of message failed. Error writing temporary file." or we warm the user that we cannot include the attachment and ask him/her to continue without the attachment. Also, I check the mail compose code for all the write call we do to be sure we correctly report errors. This is working fine for me now.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Wait, I have just reproduced the problem :-(
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Ok, I found the problem and should have a fix soon. The problem is that neOutputStream bufferize write operation and therefore write call never failed unless we write more than the buffer can hold. When we close the file, the fluch function is executed and failed but as the close function does not return an error code, the only way to catch it is to call the failed function after closing the file.
neither write, flush, close or failed let you know that something went wrong when the disk is full :-( At this point, all I can do is to test the file size before passing it to smtp to be sure is not empty. I'll do that and then open a new bug report for fixing nsOutputStream.
Status: REOPENED → ASSIGNED
varada, can you review the fix.
Whiteboard: relnote-user → relnote-user, have fix
Comment on attachment 49973 [details] [diff] [review] Proposed fix, v1 This should catch most of the problems and the chances that we will send a partial message is low. I guess any more major changes at this point will be too late for the branch. We should have another bug for opened for this. r=varada
Attachment #49973 - Flags: review+
sr=bienvenu - this won't handle the case that the file was partially written, but I guess it's better than nothing.
Fixed in the trunk, waiting PDT approval for the branch.
Whiteboard: relnote-user, have fix → relnote-user, Fixed in the trunk
I filed bug 100687 for the underline problem with nsOutputStream.
whoa, I think this breaks send later on the trunk, so hold off checking it into the branch. I think you should probably back out the change from the trunk as well. I'l l make sure that backing it out fixes the send later problem. The problem is that getSize can return 0 even though there is data in the file - it seems to be some sort of race condition - if you step through the code, it works fine, but if you run it, it fails.
http://bugzilla.mozilla.org/show_bug.cgi?id=100747 opened for blocker introduced by this change. I'm sorry, I should have caught this in the review.
Maybe we should forget about it for the branch as it's likely we will need first to fix nsOutputStream.
Depends on: 100687
Whiteboard: relnote-user, Fixed in the trunk → relnote-user,
I moved the file size check code after I close the file and it seems to work properly.
What do you think we should do JF, should we punt for the branch and release note or do we want to get a newer patch that fixes the regression?
I would say let's try one more time. I'll checking the new patch in the trunk today and if everything is fine after 1-2 days of cooking, let's try it on the branch.
The only difference in my new patch is that I first close the file and then check the file size.
Did you move the file size checking code to after the close? It's hard to tell from the patch. Did you try this without setting breakpoints?
Yes, I moved it after the close and I ran it from a dos shell without debugger. Before I change the code I was able to reproduce the regression at 100%. Now that I have changed it, I cannot reproduce it.
...and I have tested it on Mac and Windows.
ok, r=bienvenu, then.
Comment on attachment 50097 [details] [diff] [review] Patch for regression, v1 r=varada
Attachment #50097 - Flags: review+
Fixed again in the trunk
Whiteboard: relnote-user, → relnote-user, Fixed in the trunk
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: relnote-user, Fixed in the trunk → relnote-user, Fixed in the trunk,[correctness]
check it in - PDT+
Whiteboard: relnote-user, Fixed in the trunk,[correctness] → relnote-user, Fixed in the trunk,[correctness],PDT+
Fixed in the branch too.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Whiteboard: relnote-user, Fixed in the trunk,[correctness],PDT+ → relnote-user, [correctness],PDT+
Using windows build 2001-09-25 branch, on a 133 Win98 system, I was able to take the disk space down to prompt an error stating Send was successful, but copy to Sent folder failed due to low disk space. I cancelled the Compose window, cleaned up some disk space and retrieved the message. It was complete. This is verified for Windows. Laurel will verify for linux.
Using sep26 commercial 0.9.4 branch build on linux rh6.2: I think it's OK for the most part. I have one issue that I'll separate out to a new bug. Using sep26 branch with Send Page or New Msg with varied attachments: 1. If the tmp dir was full, on Send (or save Draft) I saw an error "couldn't write to tmp file". Message not sent, stayed in compose window. 2. If the tmp file could be partially written, but not enough space to finish for the attachment I saw an error "problem with attachment, do you want to send the message without the attached file?" If yes, message sent fine. If no, stayed in compose window. 3. If all was ok with the tmp directory, message was sent fine and the message received fine (received on different machine/user) with attachment(s) intact. I never received a "send completed but copy to sent folder failed" error in any instances I tried. I saw that the Sent folder got a header in the thread pane, but had no body or attachment. 4. In the situation for #3 above, if I'd sent myself/same machine the message, once I freed up some space the message was received fine with attachment(s) intact. The Sent copy never was fully available. So, I think this is OK except for the incomplete Sent folder copy. I will log a separate bug about that. Otherwise, I'm considering this verified on the branch.
New bug for no error that sent copy failed is logged as bug 102030.
removing dependency since this bug was fixed.
No longer depends on: 100687
OK using nov19 commercial trunk build: linux rh6.2 Same results as when tested on 9-27. Assum other platforms ok, too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.