Closed Bug 57902 Opened 21 years ago Closed 21 years ago

"Send Page" fails to forward the included page - out of disk space


(MailNews Core :: Backend, defect, P3)

Windows NT


(Not tracked)



(Reporter: tao, Assigned: bugzilla)



(Keywords: dataloss, Whiteboard: relnote-user, [correctness],PDT+)


(2 files)

build: 2000-10-23-09-MN6

1. GO visit a page:
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
Keywords: relnoteRTM
QA Contact: esther → laurel
Whiteboard: relnote-user
Keywords: dataloss, ui
Another low disk space bug is the FTP download bug 82478
Keywords: nsenterprise
Adding nsenterprise+.  I'm curious to know how hard this would be.  I'm cc'ing
ducarroz (feel free to reassign).
Target Milestone: --- → mozilla0.9.4
over to Jean-Francois & varada.
Assignee: mscott → ducarroz
this work will happen during .9.5 but is still scheduled to land on the branch.
Keywords: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5
per comments changing to 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. 
Closed: 21 years ago
Resolution: --- → WORKSFORME
Wait, I have just reproduced the problem :-(
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
Attached patch Proposed fix, v1Splinter Review
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.
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.
Attachment #49973 - Flags: superreview+
Fixed in the trunk, waiting PDT approval for the branch.
Blocks: 99508
Whiteboard: relnote-user, have fix → relnote-user, Fixed in the trunk
No longer blocks: 99508
Blocks: 99508
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. 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
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
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.
Attachment #50097 - Flags: superreview+
Comment on attachment 50097 [details] [diff] [review]
Patch for regression, v1

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.
Closed: 21 years ago21 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.
Keywords: vtrunk
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. 
Blocks: 56565
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.