Problem description: Documents produced by LO 3.5.x and 3.4.x fail to open correctly when sent through Outlook Web Access; issue not existing in AOO or OOo3.3.The document cannot be open, but if unzipped and zipped, then it open correctly. Steps to reproduce: 1. Create a document in LO or edit an existing one, save it under ODF. 2. Send it through OWA (Outlook Web access) 3. After reception, it's impossible to open the received document. 4. Unzip the received document; zip it again 5. You can now open it. Current behavior: Basically one cannot open the document that has been created under LO and sent through Outlook Web Access. If the document has been created under OOo 3.3 or AOO, LO will be able to open it. Expected behavior: The document should open normally and unzipping , then zipping it should not be necessary to open the document. Platform (if different from the browser): Windows XP, Vista and 7.
I can confirm this problem. In our case the files show 0 kb filesize after receiving in OWA.
It's common for mail-virus-scanners to do things with mails. What's the diff between the sent and received document? And between the received and rezipped document? What you you open the document with, in step 3) and 5) ? Libreoffice? I tried with LO 3.5.0alpha0+ (Build ID: b32ae7f) and send an .odt via OWA, works great for me. But the doc is unchanged.
To even begin to try to work around this horrible Outlook (or more likely Outlook virus checker) stupidity - assuming it can be worked around I need the following: * a very simple document for which this is the case: "Hello World" in writer would do. * the -identical- simple document when loaded and re-saved in Apache OpenOffice. Now we need to take these two documents and send them through the mail server & verify that it destroys -only- the LibreOffice one. Then - please attach both of the documents (clearly labelled) to the bug. Then we can look at the difference and try to suggest some fixes; perhaps it is work-around-able, perhaps not. Without that, it's impossible to know why a given Outlook/Exchange setup we don't have access to is truncating certain documents to zero length.
Created attachment 63086 [details] The 4 test documents zipped in this file.
As Charles said, I've done the test on OS X, with my professional mail account. Here is the test files. - Original LiBo file (12kb) - OWA version (0kb) - Original OOo file (8kb) - OWA version (8kb)
With the test cases presented I'm going to mark as NEW instead of NEWINFO. Maybe this one should be high priority? I'll leave it at medium for now but I think high might be deserved.
Just one more information on the problem description. It occurs whatever mail client used to send the LO attached files, and only with OWA (Outlook Web Access 2003 or 2010, any browser) as mail client to receive : a size of 0b (or 2b) are downloaded when opening attached files. When opening the same message with a client as MsOutlook, all files are ok. Best regards.
Some differences at extraction around ordering in the streams and/or directory: $ unzip ../originalOOo.odt Archive: ../originalOOo.odt extracting: mimetype creating: Configurations2/statusbar/ inflating: Configurations2/accelerator/current.xml creating: Configurations2/floater/ creating: Configurations2/popupmenu/ creating: Configurations2/progressbar/ creating: Configurations2/menubar/ creating: Configurations2/toolbar/ creating: Configurations2/images/Bitmaps/ inflating: content.xml inflating: manifest.rdf inflating: styles.xml extracting: meta.xml inflating: Thumbnails/thumbnail.png inflating: settings.xml inflating: META-INF/manifest.xml $ unzip ../originalLIBO.odt Archive: ../originalLIBO.odt extracting: mimetype extracting: meta.xml inflating: settings.xml inflating: content.xml extracting: Thumbnails/thumbnail.png inflating: manifest.rdf creating: Configurations2/images/Bitmaps/ creating: Configurations2/popupmenu/ creating: Configurations2/toolpanel/ creating: Configurations2/statusbar/ creating: Configurations2/progressbar/ creating: Configurations2/toolbar/ creating: Configurations2/menubar/ inflating: Configurations2/accelerator/current.xml creating: Configurations2/floater/ inflating: styles.xml inflating: META-INF/manifest.xml Which is interesting - although that ordering should really have -no- impact at all. Don'tcha love all those empty Configurations2/ directories that are created - most likely as a random programming side-effect of our ultra-lame UNO package / path handling implementations ;-)
Only in originalLIBO/Configurations2: toolpanel the only structurally different piece - and that is an empty directory ;-) Binary files originalOOo/Thumbnails/thumbnail.png and originalLIBO/Thumbnails/thumbnail.png differ is interesting; but: $ file originalOOo/Thumbnails/thumbnail.png originalOOo/Thumbnails/thumbnail.png: PNG image data, 181 x 256, 8-bit/color RGB, non-interlaced $ file originalLIBO/Thumbnails/thumbnail.png originalLIBO/Thumbnails/thumbnail.png: PNG image data, 181 x 256, 8-bit/color RGB, non-interlaced Same size, same settings; the only difference ImageMagick's 'compare' can see is a trivial, single pixel rendering difference at the end of 'World's d - which surely can't be the issue.
Other interesting diffs that may be useful to add into the working document to see if we can isolate what breaks it: diff -ur originalOOo/manifest.rdf originalLIBO/manifest.rdf --- originalOOo/manifest.rdf 2012-06-15 17:33:30.000000000 +0100 +++ originalLIBO/manifest.rdf 2012-06-15 17:29:58.000000000 +0100 @@ -1,9 +1,18 @@ <?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> - <ns1:StylesFile xmlns:ns1="http://docs.oasis-open.org/ns/office/1.2/meta/odf#" rdf:about="styles.xml"/> - <ns2:Document xmlns:ns2="http://docs.oasis-open.org/ns/office/1.2/meta/pkg#" rdf:about=""> - <ns2:hasPart rdf:resource="content.xml"/> - <ns2:hasPart rdf:resource="styles.xml"/> - </ns2:Document> - <ns3:ContentFile xmlns:ns3="http://docs.oasis-open.org/ns/office/1.2/meta/odf#" rdf:about="content.xml"/> + <rdf:Description rdf:about="styles.xml"> + <rdf:type rdf:resource="http://docs.oasis-open.org/ns/office/1.2/meta/odf#StylesFile"/> + </rdf:Description> + <rdf:Description rdf:about=""> + <ns0:hasPart xmlns:ns0="http://docs.oasis-open.org/ns/office/1.2/meta/pkg#" rdf:resource="styles.xml"/> + </rdf:Description> + <rdf:Description rdf:about="content.xml"> + <rdf:type rdf:resource="http://docs.oasis-open.org/ns/office/1.2/meta/odf#ContentFile"/> + </rdf:Description> + <rdf:Description rdf:about=""> + <ns0:hasPart xmlns:ns0="http://docs.oasis-open.org/ns/office/1.2/meta/pkg#" rdf:resource="content.xml"/> + </rdf:Description> + <rdf:Description rdf:about=""> + <rdf:type rdf:resource="http://docs.oasis-open.org/ns/office/1.2/meta/pkg#Document"/> + </rdf:Description> </rdf:RDF> diff -ur originalOOo/META-INF/manifest.xml originalLIBO/META-INF/manifest.xml --- originalOOo/META-INF/manifest.xml 2012-06-15 17:33:32.000000000 +0100 +++ originalLIBO/META-INF/manifest.xml 2012-06-15 17:29:58.000000000 +0100 @@ -1,22 +1,12 @@ <?xml version="1.0" encoding="UTF-8"?> -<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0"> +<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0" manifest:version="1.2"> It would be interesting to see if the ODF 1.2 tags are what cause the grief - potentially OWA is allergic to ODF 1.2 ;-) Patrice - any chance of checking to see what file Apache OO.o 3.4 produces (this should be much more similar to ours), and whether that suffers the same problem ? Another thing to try is to unzip originalLIBO.odt and re-zip it - see if that has an effect. Finally - I hope you filed this bug with Microsoft: ultimately it is really their issue - they should not be corrupting & truncating valid ODF documents going through their software ! :-)
(In reply to comment #10) The problem coudn't consist in the zip process? In fact, when unzip the original lo.odt, without any change in files contents, and zip again, the new.lo.odt pass the test and no problem occurs. Other information, the same problem occurs with other version of ODF format (1.2 non extended or 1.0/1.1) with LibreOffice.
Quite agree with l.dayot. When reading the number of options in man zip here : http://pwet.fr/man/linux/commandes/zip I wonder if it could be a special config which triggers a deletion from OWA. In my job, we found a similar problem of file transfert according to the zip tool used before transfert. I don't know at all OWA but : - could it be possible to have details logs of OWA ? - is there an existing bugtracker which would refer a zip problem ?
Hi, After some analysis and tests, we found that the problem came from meta.xml included in the ODF document. When you delete it, then replace it with an identical meta.xml, the problem is solved. The same operation with any other file in the ODF document doesn't solve the problem. We can guess the problem is due to a poor zipping of meta.xml. Best regards, Frederic Vuillod StarXpert
What's the status of this bug? It's been a month, so I'm just checking-in. Is anyone working on a patch or making some test builds to try to tweak the file compression? It sounds like a real showstopper for anyone who uses OWA or has clients who use OWA. There are a couple of open questions re: this bug on the Ask.LO site (e.g. http://ask.libreoffice.org/question/804/why-do-libreoffice-attachments-become-2-bytes/). I'm hoping to get those questions closed as soon as possible -- I'd like to send a strong message that it's possible to use LO in a business setting, even if one is required to use non-Free applications like OWA. I'm happy to test out builds or run some test files through OWA if that will help us squash this bug. Thanks!
If this message looks like it comes from a Bugzilla n00b, it's because it does. Apologies for any inconvenience! Am I correct (or close enough) if I guess that characterizing this bug properly is a problem, because one cannot have both OpenOffice and LibreOffice installed on the same computer at the same time? Which leads to that one cannot create comparable ODF files with ease (installing, uninstalling and reinstalling Open/LibreOffice will likely grow old pretty fast for most of us...) I have only searched this morning, when this bug hit me personally, and having both OO and LibO is not possible on several of the old/big Linux distros, according to the documentation/wikis/forums which I have thus far checked. Fedora, Debian, CentOS, LinuxMint and Ubuntu all claim "you don't need both", "they cannot coexist" or words to that effect. I have not found any detailed/technical explanation for why the coexistence is impossible, though, at least not yet. a) Is it really true that LibreOffice and OpenOffice *cannot* be installed on the same Linux? Is this also true for Windows (XP in my case)? b) If a) really is true ATM, is there something LibreOffice as a project could do in the near future to make it possible to have both OO and LibO installed on (at least some) Linux(es) and/or maybe Windows XP and 7? c) Failing b), does anyone already have an effective package of scripts to quickly and automatically swap between using LibO and OO (on LinuxMint 13 or Ubuntu 12.04 in my case), to make it easy to test this bug further? I will have access to OWA until 9th September, but likely not after that, so I would like to get cracking with test files ASAP, if more of them are needed. d) What would be a better place to ask questions a) and b)? They touch on so much more than just this bug. This is the first concrete case that I have seen where having both LibO and OO would be useful, or actually more than useful: pretty much necessary. And I am not holding my breath for that Microsoft would fix OWA any time soon, however complete a bug description the open source community manages to come up with. So getting this problem to go away most likely is up to us. Thank you for you time and happy hacking. Ronja
> If this message looks like it comes from a Bugzilla n00b, it's because it does. > Apologies for any inconvenience! newbies are persons wanting to learn, so they are generally treated well in linux communities. Welcome. > "they cannot coexist" or words to that effect. I have not found any > detailed/technical explanation for why the coexistence is impossible, though, > at least not yet. Mixing the two things would be like mixing hot and cold water - it can't be both at the same time. (until the libreoffice project has changed so much it isn't water anymore) > Ubuntu 12.04 in my case), to make it easy to test this bug further? I will have > access to OWA until 9th September, but likely not after that, so I would like > to get cracking with test files ASAP, if more of them are needed. I have permanent access to OWA, and in my testing the problem isn't SENDING it with OWA. It's RECEIVING with OWA. Tried: a) Sending from OWA to Thunderbird -> opens OK b) Sending from Thunderbird to Thunderbird -> opens OK c) Sending from OWA to OWA -> opens as 0-byte document (calc tries to import it) d) Sending from Thunderbird to OWA -> reports wrong attachment size (+3kB) and opens as 0-byte document (calc tries to import it) Thus, I think this bug probably should be marked as "fails to open correctly when RECEIVED through Outlook Web Access". Unless someone actually got the problem from sending docs from OWA to a non-OWA "mail client". Also tried sending the file just renamed to different extensions (), but the OWA webmail interface messes it up still. Probably trying to be smart with "file magic numbers" For information, fetching the _same mail_ from the _same server_ via WebDAV (http://davmail.sf.net) into Thunderbird works great. So I'm about 95% this is an OWA bug. Now where do we file that... (Could probably work around of course, just to be nice with M$) I use the basic HTML version of OWA, but there are more "sophisticated" versions with activeX and whatnot.
Is it OK to change this bug's subject to "ODF documents produced by LO 3.5.x and 3.4.x fail to open correctly when received as Outlook Web Access attachments"? Rationale: 1) Charles' description testifies to the "received" aspect, as do Jaqueline's, l.dayot's and Arno's confirmations and Patrice's test file report. 2) I have seen that the same file, produced with LibO 3.5.* but saved in DOC format works just fine as an OWA email attachment. It would be nice to receive a few confirmations on 2, though, to be on the safe side. Any objections? I nobody screams, say, before Friday, I'll edit the subject.
(In reply to comment #17) > 2) I have seen that the same file, produced with LibO 3.5.* but saved in DOC > format works just fine as an OWA email attachment. It would be nice to receive > a few confirmations on 2, though, to be on the safe side. I confirm that when send a .doc attachment, OWA accept to open the document. > > Any objections? I nobody screams, say, before Friday, I'll edit the subject. No objection. Don't forget that StarXpert (comment #13) found a bug in meta.xml in the zip file ODF. It seems to be a OOo bug and not a OWA one.
(In reply to comment #17) > 2) I have seen that the same file, produced with LibO 3.5.* but saved in DOC > format works just fine as an OWA email attachment. It would be nice to receive > a few confirmations on 2, though, to be on the safe side. > I confirm that when send a .xls (or .xlsx) attachment, OWA accept to open the document. If I use .ods it won't work. I will also point to comment #13. I have also the feeling there is something wrong in the meta.xml.
(In reply to comment #13) > When you delete it, then replace it with an identical meta.xml, the problem is > solved. > Not having access to OWA - can someone please attach two files to this issue, one that shows the problem, and a second one, *exactly* identical to the previous one, but with the "fix" from above applied, and _validated_ to pass OWA correctly? That would help tremendously to binary-diff it.
Created attachment 65971 [details] LibO original 1
Created attachment 65972 [details] LibO original 2
Created attachment 65973 [details] LibO original 3
Created attachment 65974 [details] LibO original 4 This (and the previous three) are original LibO files -
Created attachment 65975 [details] Original 1, but re-zipped
Created attachment 65976 [details] Original 2, but re-zipped
Created attachment 65977 [details] Original 3, but re-zipped
Created attachment 65978 [details] Original 4, but re-zipped This and the previous three samples are manually re-zipped. I would need someone with access to OWA to validate that the "LibO original N" files don't make it through, whereas the following re-zipped ones do. Thanks a lot!
(In reply to comment #28) > Created attachment 65978 [details] > Original 4, but re-zipped > > This and the previous three samples are manually re-zipped. I would need > someone with access to OWA to validate that the "LibO original N" files don't > make it through, whereas the following re-zipped ones do. Thanks a lot! Thanks a lot for your samples! I send all of them to my OWA-Account with following results: LibO original 1: works LibO original 2: works LibO original 3: does not work - 100 byte LibO original 4: works LibO rezipped 1: works LibO rezipped 2: works LibO rezipped 3: works LibO rezipped 4: works As you can see only the spreadsheet-file (Sample 3) makes some trouble but after rezipping the problem is gone, great. Maybe some other could check also with OWA.
(In reply to comment #28) > Created attachment 65978 [details] > Original 4, but re-zipped > > This and the previous three samples are manually re-zipped. I would need > someone with access to OWA to validate that the "LibO original N" files don't > make it through, whereas the following re-zipped ones do. Thanks a lot! I confirm the results in comment #29. Thanks a lot for your work. Unfortunately we have to use OWA and not receiving odf-atachments is our hardest LibO-problem. Used: OWA with Exchange Server 2003
Ok, so a pattern seems to develop. So far, all files that are confirmed to pass through OWA unharmed, look like this at the start: unzip -l <file>: 39 Stored 39 0% 0c32c65e mimetype 14835 Stored 14835 0% f9791615 Pictures/random_pic.png 1047 Stored 1047 0% 0e4eaf1f meta.xml and those that get mangled look like this: unzip -l <file>: 47 Stored 47 0% a8ac2633 mimetype 1047 Stored 1047 0% 0e4eaf1f meta.xml Waiting for one more trial to finish, and then we'd need to re-arrange streams in the zip storage it seems.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b2440f985f8676393094140cfd919ef82161e31 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=38a2e86db2d1f23b95f705bfe1b626f419f4e290 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=54ba550c31c7de1e7d1bf99042883aa4ae6863c6 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=899c338ccde3053aaa9751cd932fc0bdefca9d95 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixes committed to master, still hunting down corner cases, so we'll likely miss 3.6.4 with this. We should have daily builds with the fix by tomorrow here: http://dev-builds.libreoffice.org/daily/
Any feedback on the daily builds or the 4.0 alpha/beta ? I guess if the Beta survives for a week or two with this - and no obvious deluge of complaints - we could back-port for 3.6.5 without overmuch concern. The patch seems reasonable to me. It's unclear to me that encrypting meta.xml in an encrypted document is the right approach though - is that really what the spec. says ?
(In reply to comment #37) > It's unclear to me that encrypting meta.xml in an encrypted document is the > right approach though - is that really what the spec. says ? > It was apparently doing that before already, and beyond that it is clearly a bad idea not to encrypt the potentially quite valuable meta data... ;)
Hi, I've created a .odt with LO 4 Beta, no problem with OWA. Best regards, Stéphane.
skerain: we're not aware of any problems caused in 4.0 by this fix either (yet) - but of course wider testing happens between 4.0.0 and 4.0.1. Thorsten - you have my +1 whenever you're happy to back-port the fix to -3-6 of course :-) Wow I hate working around this sort of weirdo Microsoft issue.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=577dd810d94374d634b46515a19127bc26dae516&h=libreoffice-3-6 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=553724beeb7710e9dbfb70d53913fe9b37d87eed&h=libreoffice-3-6 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=28e6acb724671e72bd4e2e207a61fee0c94c432b&h=libreoffice-3-6 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6892bd5511bac086000efac9c865a5a148202dc&h=libreoffice-3-6 Fix fdo#51121 OWA misbehaviour with uncompressed meta.xml It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.