27460 - Copy to sent folder fails upon sending

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[esther]

Using builds 20000211m14 builds on Win98, mac and linux if you use a profile 
with a migrated pref, copy to sent folder is not working.  If you have the 
check box checked and are pointing to a folder that exists and has been opened 
before then Send a message, you will get an error message that the copy failed.

1. Launch Messenger (selecting a profile that has and account that has been 
migrated and had the Copy to Sent folder checked before migrating) Note: it must 
be an account that has been migrated or you'll run into a different bug 
regarding sending. 
2. Select the migrated account and click Get Msg (preferrably don't have Save 
Password selected), give password.
3. Select New Msg and enter data then click Send.

Result:  Notice you will get an error message that Copy to Sent folder failed 
even when you have the boxed checked and pointing to an existing folder and the 
folder has been opened before (meaning it has a .msf file).
Expected: Message to get sent and a copy to the Sent folder.

Comment 1

[Richard Zach]

*** Bug 27452 has been marked as a duplicate of this bug. ***

Comment 2

[Richard Zach]

*** Bug 27479 has been marked as a duplicate of this bug. ***

Comment 3

[Richard Zach]

I'm not sure what esther means by "this has to be a migrated account". This
happens to me also on a new profile with accounts explicitly set to copy to sent
folders.  It happens regardless of what kind of account (POP or IMAP) you send
from, and regardless of whether the Sent folder is a local folder or IMAP. 

Comment 4

[(not reading, please use [e-mail] instead)]

see bug #27568 for details on where it is failing.

should this be a rhp bug?

Comment 5

[Richard Zach]

*** Bug 27568 has been marked as a duplicate of this bug. ***

Comment 6

[rhp (gone)]

This one is me. Adding some comments:

it fails on line 3897 of nsMsgSend.cpp

  while (! inputFile.eof())
        {
    if (!inputFile.readline(ibuffer, ibuffer_size))
    {
***   status = NS_ERROR_FAILURE;
      goto FAIL;
    }

nsMsgComposeAndSend::MimeDoFCC(nsFileSpec * 0x040b1980, int 0, const char * 
0x01f12730, const char * 0x040b4e10, const char * 0x040b27a0) line 3897
nsMsgComposeAndSend::DoFcc() line 2941 + 74 bytes
nsMsgComposeAndSend::DoDeliveryExitProcessing(unsigned int 0, int 0) line 2882 
+ 
8 bytes
nsMsgComposeAndSend::DeliverAsMailExit(nsIURI * 0x044f0d44, unsigned int 0) 
line 
2903
MailDeliveryCallback(nsIURI * 0x044f0d44, unsigned int 0, void * 0x046eb200) 
line 2539
nsMsgDeliveryListener::OnStopRunningUrl(nsMsgDeliveryListener * const 
0x044f05b0, nsIURI * 0x044f0d44, unsigned int 0) line 82 + 21 bytes
nsUrlListenerManager::BroadcastChange(nsIURI * 0x044f0d44, nsUrlNotifyType 
nsUrlNotifyStopRunning, unsigned int 0) line 97
nsUrlListenerManager::OnStopRunningUrl(nsUrlListenerManager * const 0x044f0d00, 
nsIMsgMailNewsUrl * 0x044f0d44, unsigned int 0) line 110 + 18 bytes
nsMsgMailNewsUrl::SetUrlState(nsMsgMailNewsUrl * const 0x044f0d44, int 0, 
unsigned int 0) line 105
nsSmtpProtocol::ProcessProtocolState(nsIURI * 0x044f0d44, nsIInputStream * 
0x044b62f8, unsigned int 312, unsigned int 36) line 1373
nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x044b7ac0, nsIChannel * 
0x044b6534, nsISupports * 0x044f0d44, nsIInputStream * 0x044b62f8, unsigned int 
312, unsigned int 36) line 172 + 32 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x046aff90) 
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x046a9f50) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x046a9f50) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ce6d40) line 487 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000b0926, unsigned int 49361, unsigned int 0, 
long 13528384) line 975 + 9 bytes
USER32! 77e71820()
00ce6d40()

Comment 7

[rhp (gone)]

This is a bad problem, but a very easy fix. It's a problem were the macro 
IS_SPACE() not working directly on a "const char *" buffer, but if I just do 
the comparison by hand, it works fine. We were stripping off the final CRLF on 
the message incorrectly and then reading this file during the copy operation 
failed. We have to take this fix which I have in my tree on this one:

Index: mozilla/mailnews/compose/src/nsMsgSend.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/compose/src/nsMsgSend.cpp,v
retrieving revision 1.162
diff -p -r1.162 nsMsgSend.cpp
*** nsMsgSend.cpp	2000/02/11 01:29:58	1.162
--- nsMsgSend.cpp	2000/02/13 21:30:00
*************** nsMsgComposeAndSend::SnarfAndCopyBody(co
*** 2386,2395 ****
    {
  		// strip out whitespaces from the end of body ONLY.
  		while (attachment1 [details] [diff] [review]_body_length > 0 &&
!       IS_SPACE (attachment1 [details] [diff] [review]_body [attachment1 [details] [diff] [review]_body_length - 1]))
      {
        attachment1 [details] [diff] [review]_body_length--;
      }
      if (attachment1 [details] [diff] [review]_body_length <= 0)
        attachment1 [details] [diff] [review]_body = 0;
      
--- 2386,2396 ----
    {
  		// strip out whitespaces from the end of body ONLY.
  		while (attachment1 [details] [diff] [review]_body_length > 0 &&
!       (attachment1 [details] [diff] [review]_body[attachment1 [details] [diff] [review]_body_length - 1] == ' ') )
      {
        attachment1 [details] [diff] [review]_body_length--;
      }

Comment 8

[Phil Peterson]

Is there a bug in IS_SPACE? 

Comment 9

[rhp (gone)]

I don't think there is. I was thinking that, but if I change the code to 
something like: 

  const char *ptr = attachment1 [details] [diff] [review]_body [attachment1 [details] [diff] [review]_body_length - 1];
  if (IS_SPACE(*ptr))
    blah, blah...

it works...but all my other attempts at munging "attachment1 [details] [diff] [review]_body 
[attachment1 [details] [diff] [review]_body_length - 1];" in the call to IS_SPACE() didn't seem to work. 
Something is going on with how the compiler is expanding the macro that I'm not 
getting, and since this printing bug is taking way more time than it should, I 
went with my fix.

- rhp

Comment 10

[leger]

Putting on PDT+ radar for beta1.

Comment 11

[rhp (gone)]

All better now.

- rhp

Comment 12

[Richard Zach]

Verified on Linux build 2000.02.15.10

Comment 13

[esther]

Zach, the reason I mentioned "if you use a profile with a migrated pref" is 
because to see this particular bug you couldn't use a New Profile/Account added 
manually.  With a New Profile/no migration you saw differnt bug 27424, where the 
Send functionaliy was broke and user never got an error message.  The steps were 
specific to see a specific result.  Also, this was logged against all platforms, 
it must be verified on all platforms.  Thanks for your help in verifying it on 
linux, I will verify it for Win32 and Mac with today's builds.  In the future if 
the bug is on all platforms, and you are verifying it on one platform only, 
please note that in the comments and leave the bug in the Resolved/Fixed state 
until someone has verified the other platforms.  Thanks again.

Comment 14

[esther]

Update:  Using mozilla win32 build 2000-02-16-16m14 and commercial build 
2000-02-16-08 on Mac this is fixed.

Comment 15

[esther]

CC'ing [e-mail] for notification purposes when comments are added