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

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[tao]

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...

Comment 1

[tao]

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...

Comment 2

[lchiang]

ah!  we have all sorts of bug reports on out of disk space :-)  We don't give a 
warning right now.

Comment 3

[laurel]

Related (disk space) bugs:  bug 55814, bug 49868, bug 32443

Will include as part of general out of disk space relnote

Comment 4

[Jacek Piskozub]

Another low disk space bug is the FTP download bug 82478

Comment 5

[scottputterman]

Adding nsenterprise+.  I'm curious to know how hard this would be.  I'm cc'ing
ducarroz (feel free to reassign).

Comment 6

[Scott MacGregor]

over to Jean-Francois & varada.

Comment 7

[Scott MacGregor]

this work will happen during .9.5 but is still scheduled to land on the branch.

Comment 8

[Hong Kwon]

per comments changing to ASSIGNED

Comment 9

[grega]

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.

Comment 10

[Jean-Francois Ducarroz]

I don't have a status. I haven't looked at it yet!

Comment 11

[Jean-Francois Ducarroz]

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.

Comment 12

[Jean-Francois Ducarroz]

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. 

Comment 13

[Jean-Francois Ducarroz]

Wait, I have just reproduced the problem :-(

Comment 14

[Jean-Francois Ducarroz]

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.

Comment 15

[Jean-Francois Ducarroz]

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.

Comment 16

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v1

Comment 17

[Jean-Francois Ducarroz]

varada, can you review the fix.

Comment 18

[varada]

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

Comment 19

[David :Bienvenu]

sr=bienvenu - this won't handle the case that the file was partially written,
but I guess it's better than nothing.

Comment 20

[Jean-Francois Ducarroz]

Fixed in the trunk, waiting PDT approval for the branch.

Comment 21

[Jean-Francois Ducarroz]

I filed bug 100687 for the underline problem with nsOutputStream.

Comment 22

[David :Bienvenu]

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.

Comment 23

[David :Bienvenu]

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.

Comment 24

[Jean-Francois Ducarroz]

Maybe we should forget about it for the branch as it's likely we will need first
to fix nsOutputStream.

Comment 25

[Jean-Francois Ducarroz]

I moved the file size check code after I close the file and it seems to work
properly.

Comment 26

[Scott MacGregor]

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?

Comment 27

[Jean-Francois Ducarroz]

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.

Comment 28

[Jean-Francois Ducarroz]

Attachment: Patch for regression, v1

Comment 29

[Jean-Francois Ducarroz]

The only difference in my new patch is that I first close the file and then
check the file size.

Comment 30

[David :Bienvenu]

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?

Comment 31

[Jean-Francois Ducarroz]

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.

Comment 32

[Jean-Francois Ducarroz]

...and I have tested it on Mac and Windows.

Comment 33

[David :Bienvenu]

ok, r=bienvenu, then.

Comment 34

[varada]

Comment on attachment 50097 [details] [diff] [review]
Patch for regression, v1

r=varada

Comment 35

[Jean-Francois Ducarroz]

Fixed again in the trunk

Comment 36

[Jaime Rodriguez, Jr.]

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Comment 37

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 38

[Jean-Francois Ducarroz]

Fixed in the branch too.

Comment 39

[esther]

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.

Comment 40

[laurel]

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.
 

Comment 41

[laurel]

New bug for no error that sent copy failed is logged as bug 102030.

Comment 42

[Scott MacGregor]

removing dependency since this bug was fixed.

Comment 43

[laurel]

OK using nov19 commercial trunk build: linux rh6.2
Same results as when tested on 9-27.
Assum other platforms ok, too.