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

VERIFIED FIXED in mozilla0.9.5

Status

P3
normal
VERIFIED FIXED
19 years ago
11 years ago

People

(Reporter: tao, Assigned: bugzilla)

Tracking

({dataloss})

Trunk
mozilla0.9.5
x86
Windows NT
dataloss
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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...
(Reporter)

Comment 1

19 years ago
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

19 years ago
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

Comment 3

19 years ago
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

Updated

18 years ago
Keywords: dataloss, ui

Comment 4

18 years ago
Another low disk space bug is the FTP download bug 82478

Updated

18 years ago
Keywords: nsenterprise

Comment 5

18 years ago
Adding nsenterprise+.  I'm curious to know how hard this would be.  I'm cc'ing
ducarroz (feel free to reassign).
Keywords: nsenterprise → nsenterprise+
Target Milestone: --- → mozilla0.9.4

Comment 6

18 years ago
over to Jean-Francois & varada.
Assignee: mscott → ducarroz

Comment 7

18 years ago
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

Comment 8

18 years ago
per comments changing to ASSIGNED
Status: NEW → ASSIGNED

Comment 9

18 years ago
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.
Keywords: nsenterprise+ → nsenterprise-
(Assignee)

Comment 10

18 years ago
I don't have a status. I haven't looked at it yet!
(Assignee)

Comment 11

18 years ago
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.
(Assignee)

Comment 12

18 years ago
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
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 13

18 years ago
Wait, I have just reproduced the problem :-(
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 14

18 years ago
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.
(Assignee)

Comment 15

18 years ago
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
(Assignee)

Comment 16

18 years ago
(Assignee)

Comment 17

18 years ago
varada, can you review the fix.
Whiteboard: relnote-user → relnote-user, have fix

Comment 18

18 years ago
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+

Comment 19

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

Updated

18 years ago
Attachment #49973 - Flags: superreview+
(Assignee)

Comment 20

18 years ago
Fixed in the trunk, waiting PDT approval for the branch.
Blocks: 99508
Whiteboard: relnote-user, have fix → relnote-user, Fixed in the trunk

Updated

18 years ago
No longer blocks: 99508

Updated

18 years ago
Blocks: 99508
(Assignee)

Comment 21

18 years ago
I filed bug 100687 for the underline problem with nsOutputStream.

Comment 22

18 years ago
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

18 years ago
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.
(Assignee)

Comment 24

18 years ago
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,
(Assignee)

Comment 25

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

Comment 26

18 years ago
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?
(Assignee)

Comment 27

18 years ago
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.
(Assignee)

Comment 29

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

Comment 30

18 years ago
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?
(Assignee)

Comment 31

18 years ago
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.
(Assignee)

Comment 32

18 years ago
...and I have tested it on Mac and Windows.

Comment 33

18 years ago
ok, r=bienvenu, then.

Updated

18 years ago
Attachment #50097 - Flags: superreview+

Comment 34

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

r=varada
Attachment #50097 - Flags: review+
(Assignee)

Comment 35

18 years ago
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+
(Assignee)

Comment 38

18 years ago
Fixed in the branch too.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: relnote-user, Fixed in the trunk,[correctness],PDT+ → relnote-user, [correctness],PDT+

Comment 39

18 years ago
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

18 years ago
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

Comment 41

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

Comment 42

18 years ago
removing dependency since this bug was fixed.
No longer depends on: 100687

Comment 43

18 years ago
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

Updated

17 years ago
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.