SaveMessageToDisk() call fails when message contains lines with CRLF ALONE

VERIFIED FIXED in M9

Status

MailNews Core
Networking
P3
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: rhp (gone), Assigned: Scott MacGregor)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
I was testing my SendLater operations and when I go to save the files off to
send them, I make the call:

rv = messageService->SaveMessageToDisk(aMessageURI, mHackTempIFileSpec,
                                       PR_FALSE, mSaveListener, nsnull);

Everything works callback wise, etc... but the file is truncated at the first
line with a CRLF only and my callback gets called with an error code.
(Reporter)

Comment 1

19 years ago
Created attachment 1133 [details]
This is an example of a mail folder that shows problem
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M9
(Assignee)

Comment 2

19 years ago
Setting to M9.
(Assignee)

Comment 3

19 years ago
I'm having trouble with this attachment. When I save the file as text, the CRLFs
are getting messed up. It would take to long to reformat the message by hand so
I'm going to wait till rich can send me the attachment diretly without going
through bugzilla.

I'll tackle this first thing in the morning.
(Assignee)

Comment 4

19 years ago
Hey Rich, I just tested save message to disk on the folder you emailed me and it
worked like a charm. It wrote the message out in its entirety to disk without a
problem.

However, I did notice that the one you sent me was NOT the one you posted in
this bug report so it may not have the conditions necessary to generate the bug.
Hmm.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 5

19 years ago
I wasn't able to reproduce any problems with actually saving the message to
disk.

but there was a problem with necko where they are returning NS_STOP_BINDING
after I read a byte range from the file. This is defined as an error code but it
should be defined as a success code. I've been trying to get them to change that
for a couple weeks but it hasn't happened yet. I added a work around to hide it
until they can change the code.

Marking as fixed.

Updated

18 years ago
QA Contact: lchiang → ppandit

Comment 6

18 years ago
Par, pls verify.

Comment 7

18 years ago
In mailnews/base/public/nsIMessageService.idl, the function is
void SaveMessageToDisk(in string aMessageURI, in nsIFileSpec aFile,
                            in boolean aGenerateDummyEnvelope,
                            in nsIUrlListener aUrlListener, out nsIURI aURL,
                            in boolean canonicalLineEnding);

Do you have a testcase available to verify this bug? Was there an attachment I
can load?

Par

Comment 8

18 years ago
Forget the javascript idl stuff.
Using a debug build from 2/14/00 on Window NT 4.0

Set a breakpoint in two locations within nsMessagenger.cpp where the function is 
called.
Added the attachment from this bug report to a POP3 inbox file
Start mozilla and opened the Inbox 
Saved the message as a file into a temp directory.
Opened message in notepad - everything looked good. 
Did a visual comparison with the original and saw no differences. 

MARKING AS VERIFIED. I assume the above procedure is correct for verification.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.