Issue 34264 - Groupwise & File->Send->Mail crasher ...
Summary: Groupwise & File->Send->Mail crasher ...
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1.3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.x
Assignee: tml
QA Contact: issues@gsl
Depends on:
Reported: 2004-09-16 15:49 UTC by mmeeks
Modified: 2017-05-20 10:27 UTC (History)
6 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Patch for 2.0.2 (985 bytes, patch)
2006-03-28 11:55 UTC, tml
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2004-09-16 15:49:10 UTC
Believe it or not, with a NULL lpszFileName in the simple MAPI structure,
Groupwise crashes; this patch fixes that:

--- shell/source/win32/simplemail/smplmailclient.cxx
+++ shell/source/win32/simplemail/smplmailclient.cxx
@@ -452,14 +452,19 @@
                 static_cast< XSimpleMailClient* >( this ), 
                 1 );
-        m_AttchmtsSysPathList.push_back( 
-            OString( 
-                aSysPath.getStr( ), 
-                aSysPath.getLength( ), 
-                osl_getThreadTextEncoding( ) ) );
+	OString aFullPath = OUStringToOString( aSysPath,
+					       osl_getThreadTextEncoding() );
+	sal_Int32 nLastSlash = aFullPath.lastIndexOf('\\');
+	OString aFileName = aFullPath.copy( nLastSlash + 1 );
+        m_AttchmtsSysPathList.push_back( aFullPath );
         m_AttachementList[i].lpszPathName = const_cast< LPSTR >(
             m_AttchmtsSysPathList.back( ).getStr( ) );  
+        m_AttchmtsSysPathList.push_back( aFileName );
+        m_AttachementList[i].lpszFileName = const_cast< LPSTR >(
+            m_AttchmtsSysPathList.back( ).getStr( ) );  
         m_AttachementList[i].nPosition = -1;               
Comment 1 christof.pintaske 2004-09-16 17:27:17 UTC
cp->tra: please have a look at it
Comment 2 tino.rachui 2004-09-17 06:49:06 UTC
The MAPI specification clearly says that lpszFileName in the MapiFileDesc may be
NULL. So this is a Groupwise bug and should be fixed by Groupwise. Isn't
Groupwise a Novell product? Any other application would have to workaround this
Groupwise problem too so the most sensible way is to fix it is to fix it in
Groupwise. OOo2.0 is more robust with regards to MAPI anyway because we are
calling MAPI outside the OOo process so that at most the MAPI calling helper
application crashes but not OOo.
Comment 3 mmeeks 2004-09-17 09:26:55 UTC
Yes, of course we can fix groupwise - and I'm working on that; however - there
is a large deployed tail of unfixed groupwise' out there - and a belt & braces
fix is  preferable.

Furthermore, as you can see, the fix is simple & painless in the extreme.

I'd greatly appreciate it getting into (at least) 2.0, and preferably 1.1.4 :-)
Comment 4 Martin Hollmichel 2004-09-21 12:18:11 UTC
set target to 1.1.4
Comment 5 mmeeks 2004-10-15 21:32:25 UTC
This also needs a 2.0 fix, that is different in senddoc.cxx 
Comment 6 Martin Hollmichel 2004-10-27 13:41:06 UTC
retarget to 1.1.5.

mh->tra: do we need to clone the issue for 2.0, is there any risk for
integration in 1.1.x series ?
Comment 7 mmeeks 2004-12-14 17:49:26 UTC
Bug #i34264# targets the 2.0 development - the patch needed substantial re-work
& I havn't tested it there yet :-)
Comment 8 pavel 2005-06-15 08:11:13 UTC
Michael: can you finish the work for 1.1.5 or should we retarget this issue?
Comment 9 mmeeks 2005-06-15 09:11:27 UTC
Pavel - this patch is trivial, correct & fixes the bug for 1.1.5.
Yes - in theory this is a G/W bug - however, clearly in order to integrate well
with G/W it helps to be a slightly friendlier customer of this interface.

ie. I'd love to see this patch, as-is in 1.1.5; no re-work is needed or suggested.
Comment 10 Martin Hollmichel 2005-08-15 11:54:05 UTC
I'm quite confused: what is the valid target here 1.1.x or 2.0 ?
Comment 11 mmeeks 2005-08-15 12:14:51 UTC
The valid target is 1.1.x - it's a trivial patch, that works around a crasher
bug with G/W.
Comment 12 tml 2006-03-28 11:55:49 UTC
Created attachment 35306 [details]
Patch for 2.0.2
Comment 13 mmeeks 2006-03-28 15:07:13 UTC
mark type correctly & target at 2.0.3
& re-assign to Tor ...
Comment 14 tml 2006-04-27 00:05:02 UTC
Hmm, I created a CWS tml03 for this but then when I tried to do cwsadd -a -f
shell (as the page says, if I
interpret it correctly, I get an error message:

cvs [server aborted]: "tag" requires write access to the repository
Comment 15 tml 2006-04-28 11:55:40 UTC
Figured out my CWS issues... Fixed in CWS tml03.
Comment 16 Mathias_Bauer 2006-05-08 15:24:28 UTC
I don't know why but tra was chosen a a QA rep for the CWS and he's not working
on this stuff anymore. So I took this over. Unfortunately my first attempt to
test the code ended with a crash in senddoc.exe (of course I didn't test with
Groupwise because I don't have it but I tested with Thunderbird).

Admittedly this was a quick and dirty test (just copy over the binaries from the
CWS into my installation) and I will do another test using the full CWS.
Unfortunately that means we might not be able to deliver this fix in 2.0.3 -
depends on how fast I can set up the CWS build and test it (and of course it
depends on how good the fix is ;-)).
Comment 17 Mathias_Bauer 2006-05-08 16:31:58 UTC
A first question about the code: what is 

sal_Int32 nLastSlash = aFullPath.lastIndexOf('\\');

supposed to do? I assume it should be used to extract the file name from the
path name but I don't see any code doing this. Currently it seems that file name
and path name are identical so you indeed avoid the crash in GroupWise but the
question remains wether your code fools MAPI clients that rely on the file name
being not a complete path. 

I'm not a MAPI expert so I don't know what usually is expected here, so I think
we should test this with some clients at least before integrating it. It seems
to work well with TB1.5 (my crash in the first attempt was caused by an STL
Debug assertion that you only get in "Non Product" builds - something to look
after but most probably not related to your patch).
Comment 18 Mathias_Bauer 2006-05-08 16:32:20 UTC
adding me to cc:
Comment 19 tml 2006-05-09 09:57:08 UTC
Ugh, thanks for looking at the patch more closely. It needs some more work.
Dunno what I was thinking.
Comment 20 tml 2006-05-09 11:05:53 UTC
Hmm, there seems to be other problems, but no crashes as such, with an OOo 2.0.2
without this patch and GroupWise. With a 2.0.2 binary from,
if I type some random text in a OOo Writer, and select File:Send:Document as
E-mail, it starts GroupWise, but nothing else happens. No crash, no dialog
asking for at lest a recipient, no nothing. GroupWise just starts and sits
there. The same happens with an OOo 2.0.2 built with the ooo-build patches (but
without win32-gw-send-mail.diff).

Or am I missing something and using the File:Send:Document as E-mail in the
wrong context? Should I already have started creating a message in the mail
client before invoking that menu item in Ooo? Or what?
Comment 21 Mathias_Bauer 2006-05-10 09:01:28 UTC
setting target (2.0.3 is done already)
@tml: we can integrate any patch as soon as you have it working. Our new target
handling that reflects our train model is to use the "2.x" target that is
changed to the next milestone as soon as it becomes clear that the fix will make
it into it. 

About the problem: don't care for my crashes, as I wrote they where caused by
STL debug assertions that are only issued in a "non pro" build. I will create a
separete issue for this problem, most often these assertions are no important
problems ATM but they show buggy code that can create more serious ones in the

About your problem with Groupwise: it's possibly a bug in GroupWise but also
possibly in the senddoc.cxx file. On a first glance I think that the OOo code
does not set the number of sent attachments at all, but maybe I overlooked
something. The current code at least works with all well known MAPI clients like
Mozilla, Thunderbird or Outlook Express.

First you should make sure that you send the correct content in lpszFileName so
that GroupWise can't be confused by it. Then we can examine the other paremeters
wether they are correct or if they work with TB etc. only "by luck".
Comment 22 tml 2006-09-26 17:24:24 UTC
It seems that this patch isn't needed with GroupWise 7.0.1 (2006-06-13), so
maybe we can just forget this whole issue. Michael?
Comment 23 mmeeks 2006-09-26 17:37:35 UTC
sure - I know this was fixed in G/W - but it's still worth us committing the
workaround for older versions, people often take a long time to update -
particularly when the client costs money :-)
Comment 24 tml 2006-09-26 19:01:40 UTC
OK, well, this is fixed in CWS tml03, which has now been resynced to m185.
Comment 25 Mathias_Bauer 2007-01-10 17:21:13 UTC
@tml: you didn't mention how you sorted your problems out. The patch is still
the same as in march but some problems are reported in may.

Comment 26 tml 2007-01-11 10:48:06 UTC
Re: the comment from Mon May 8 07:31:58 -0800 2006 : The nLastSlash variable was
a leftover that isn't needed. The current patch we have in ooo-build trunk looks
like this:

--- shell/source/win32/simplemail/senddoc.cxx	2005-02-08 11:09:48.562500000 +0530
+++ shell/source/win32/simplemail/senddoc.cxx	2005-02-09 13:59:06.140625000 +0530
@@ -64,7 +64,7 @@
 #ifndef _RTL_STRING_HXX_
-//#include <rtl/string.hxx>
+#include <rtl/string.hxx>
@@ -99,6 +99,7 @@
     StringList_t gCc;
     StringList_t gBcc;
     StringList_t gAttachments;
+	StringList_t gAttachFilenames;
     int gMapiFlags = 0;
@@ -172,7 +173,11 @@
         MapiFileDesc mfd;
         ZeroMemory(&mfd, sizeof(mfd));
         mfd.lpszPathName = const_cast<char*>(iter->c_str());    
+		rtl::OString aFullPath( mfd.lpszPathName );
+		gAttachFilenames.push_back( (const sal_Char *) aFullPath );
+		mfd.lpszFileName = const_cast<char*>(gAttachFilenames.back().c_str());    
         mfd.nPosition = sal::static_int_cast<ULONG>(-1);
Comment 27 Mathias_Bauer 2007-01-18 16:52:23 UTC
You find me confused. :-)
If you have a CWS and it is "ready for QA" I would expect that you have a build
done with the latest patch that I can test. 

Do you have one?
Or should I take the patch and apply it to a CWS of my own to get it tested?
Comment 28 cno 2007-02-14 05:18:50 UTC
Hi *,

I'm currently working on a config with OOo 2.1 (Sun build)
and GourpWise client 7.0.1 (13-6-06)
on Suse Linux thin cliënts.
Mail from OOo doesn't work. Alas.
Could it be helpful if I give some (what?) more info about the configuration??

Comment 29 tml 2007-02-14 20:41:38 UTC
> Mail from OOo doesn't work. Alas.

In what way doesn't it work? Does OOo crash, does GroupWise crash, does nothing
happen at all, do you get some error message, or do you get to compose the
message in GroupWise and send it but it actually never arrives?

For me, on one machine with the Novell Edition of OOo 2.0.4 and the same version
of GroupWise client that you have, sending mail from OOo works. I get the
GroupWise mail composition dialog, with the document already attached. 

But on another machine, trying to send mail from OOo for some reason gives an
odd Outlook error message, even though I do have the same GroupWise client on
that machine, too. Weird.
Comment 30 cno 2007-02-14 20:57:41 UTC
The error message is:
"No working e-mail configuration was found..."
Comment 31 tml 2007-02-14 21:09:58 UTC
OK, that is the same message I saw on the other machine. Probably this is then
caused by some confusion between Outlook, GroupWise and Windows about what the
preferrd MUA on the machine should be. Try reinstalling GroupWise? (I don't know
if it goes through the same codepath at all, but what happens if you open a
mailto: link in your web browser?)

(Your problem presumably has nothing to do with OOo, at least not with the
original crasher problem this bug report is about, so we should continue this
discussion by email. )
Comment 32 cno 2007-02-14 21:32:28 UTC
> so we should continue this discussion by email.

Thanks - fine offer.
If we find something of use for a wider audience, I'll come back here to report
Comment 33 Mathias_Bauer 2007-09-27 10:00:41 UTC
tml: I hate to annoy people but could you please answer my last question? I
still don't know ho to proceed. If you could attach the latest patch for your
problem to this issue and tell me that *this* patch is the one you want to get
integrated and that it fixes your problem I could proceed.

Until now we have an attached patch that obviously isn't the right one as you
reported remaining problems after the submission and we have some source code
pasted into a comment. 
Comment 34 tml 2007-09-27 12:34:16 UTC
Well, I am also confused about what to do with this. As mmeeks says in his
comment from Tue Sep 26 16:37:35 +0000 2006, the problem apparently has been
fixed in current GroupWise releases. So why bother adding workarounds to OOo for
obsolete other software?

But on the other hand, we probably will still keep the patch (as it is presented
in my comment from Jan 11 10:48:06 +0000 2007) in the ooo-build version, as it
already is there, doesn't apparently do any harm, just in case it happens to
help with some older GroupWise version, if somebody still runs such. I have no
idea how eagerly GroupWise-using sites keep their software up-to-date.