Created attachment 51713 [details]
csv data for testing
0. Download the attached file and replace email@example.com with you email address.
1. New blank writer document
2. Start Mass mail assistent
3. Next (use current document)
4. Next (e mail message)
5.1 Select address list
5.2 Add ...
5.3 Open the attached "address.csv"
5.4 Field delimiter = ,
text delimiter = "
dicimal delimiter = .
thousand delimit = <blank>
txt contains headline = checked
Encodung = UTF-8
6. Next (no letter salutation)
7.1 Edit document
7.2 F4 to show data source
7.3 Create 5 new lines and add pull id, c__lastname, c__mail, cp__email in the the first 4 rows and add the text "test1234" in the 5th.
7.4 Back to the mass mail assistent
8. Next (no individuall changes)
9.1 Send document as Email (last radio button)
9.2 To = cp__email
9.3 Subject = test
9.4 send as Adobe PDF Document
9.5 Send documents
Check you emails and the size of the attachments ... there are more than 30% off the PDF files damaged.
Windows 7 64bit
[Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", I receive mails with PDFs between few Bytes and 33kBytes
In Master we should have some fixes, I will test again as soon as a new WIN master what is able to open WRITER documents will be available.
Same problem with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]"
I would have tested with a more current version, but currently no WIN dev-builds are available. Are the latest fixes in that build?
Created attachment 51714 [details]
Source document with some pdf attachments from my test
May be damages in the PDF attachments give some hints concerning the problem?
Tested with 3.3.4 OOO330m19 Build:401
works fine for me
Thank you for your test! PDF mailmerge broke somewhere after OOo 3.1.1 with lots of lots of problems, and we (most: Caolan) had some heavy efforts here to get it running again. so your hint might be useful for "forensic" concerning this particular problem.
my mail server won't let me send 90 emails right after eachother sadly, seeing as it has some anti-spam measures.
This *sounds* like http://cgit.freedesktop.org/libreoffice/libs-extern-sys/commit/?id=491dab7d62dc42a13d56fe82cc33c2fb312ee30f i.e. http://bugs.python.org/issue4768 but that was backported to 3.4.3.
The python report is to complicated for me.
I also did not send 90 mails, most of attachments are damaged, so 5-10 should be enough.
quite possibly windows only, seeing as my 10/20 went through ok. unless its a file length thing where the troublesome versions happen to hit an exact round number boundary.
Still [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) German UI [(Build ID: 6b0de40-0bc4ff4-ca7e6f5-9125509-ce71330)]" (111111)
In a first test I only sent 5 mails with some texts, pictures, ..., 2 were ok, 3 damaged.
Then 20 documents like 2011-09-28 06:04 15 seemed ok5, 5 ones damaged
right, after setting up fakemail I can now reproduce this apparently windows-only problem.
Created attachment 53632 [details]
tmp file collisions
caolanm->mstahl: I think this is triggered from 6a5b285548f92135b6eaf220c4d4533854032aa0
e.g. same tmpfile name reused, and the mailmerge makes a *lot* of tmp files. This seems to fix it in testing anyway. Presumably in the !bKeep "I only want a unique name" path, where there is no file created then by getting a new seed every time we make it easy to hand out a file name already handed out.
How about this band-aid, i.e. basically the ye-oldy logic.
your patch was quite surprising to me,
but looking at the function and what it does now i am shocked:
the stupid thing creates a file with the generated name,
then immediately closes it again, and then later apparently
one can call a function on the TempFile object that will open
the file with the generated name again?
do i understand this right?
(seems that i missed that detail back when i did that fix...)
why don't we have an easy hack to replace this abomination with something sane?
if we don't remove it then i guess your patch could help :)
If its used to create a physical temporary file its reasonably sane. If its used to create just a unique file name which is to be safely used as the path to a temp file at some arbitrary point in the future, its not so sane methinks.
We should get rid of this thing alright, maybe two methods, one when we "just want a temp file created", i.e. just the oslCreateTemp method, and another one for the existing legacy "we want a unique filename which won't be used again for the duration of the program" which is always returned as a path in a private tmpdir created with the other method and uses a radix-36 filename off a static counter.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6560c6f07f7f71842d7314157feaca2fa4a03c9 for master (i.e. 3.5)
backported to libreoffice-3-4 (towards 3.4.5) as <http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?h=libreoffice-3-4&id=b5b7699c6a42f6cca7da6d91eac0dada9e48ee35>
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.