Issue 107688 - Complete loss of content opening broken ODT 1.2 file, the repairing function should be improved
Summary: Complete loss of content opening broken ODT 1.2 file, the repairing function ...
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO320m5
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: thorsten.martens
QA Contact: issues@framework
URL:
Keywords: regression
Depends on:
Blocks: 99999
  Show dependency tree
 
Reported: 2009-12-15 11:48 UTC by mux2005
Modified: 2017-05-20 10:24 UTC (History)
6 users (show)

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

Attachments
Opens fine in versions < 3.2. Complete data loss in 3.2 (8.37 KB, application/vnd.oasis.opendocument.text)
2009-12-15 11:49 UTC, mux2005 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description mux2005 2009-12-15 11:48:37 UTC 
The attached document opens fine with OOo versions < 3.2. OOo 3.2 complains that
the document is corrupted. If you say "Yes" to the question on whether OOo
should repair the document, the complete text is gone. Whatever property caused
OOo 3.2 to become confused seems to be injected by our document management
system (a commercial system used in the e-government sector). It seems that ALL
documents I check out from the DMS are affected. 

Tested under Linux and Windows.
Comment 1 mux2005 2009-12-15 11:49:23 UTC 
Created attachment 66646 [details]
Opens fine in versions < 3.2. Complete data loss in 3.2
Comment 2 Regina Henschel 2009-12-15 12:52:53 UTC 
DEV300m67 on WinXP fails to open the document too.

I can open the document with OOo3.1.1. If I then save it immediately, the so
saved document opens fine with OOo3.2m6. The so saved file contains something
with mimetypeapplication, which is missing in your attached document.

Does your document management system unzips the files and then zip them by their
own way?

Does the problem persists, when you open the file in OOo3.1.1, save it local,
open and save it with OO3.2 and then give it to your document management system?
Comment 3 mikhail.voytenko 2009-12-15 12:59:31 UTC 
The attached document is no valid ODF1.2 document, there is a stream
"customXml/item1.xml" that is not registered in META-INF/manifest.xml.

The earlier versions of the office had accepted such incomplete documents, that
was wrong and was recognized as a security issue.

If agree that the repairing function should be able to load the document, but
that is no showstopper from my point of view.
Comment 4 mikhail.voytenko 2009-12-15 13:01:25 UTC 
Sorry for the typo "If agree..." should be "I agree".

Taking the issue over and changing the Summary accordingly.
Comment 5 mikhail.voytenko 2009-12-16 11:32:21 UTC 
The issue was recognized as a showstopper so I am changing the Target accordingly.

There is a very easy fix, that affects the recovery scenario only. The normal
loading process is not affected at all, so the fix can be treated as absolutely
safe.
Comment 6 andreschnabel 2009-12-16 12:47:33 UTC 
@mav: 
the ODF validator at http://tools.services.openoffice.org/odfvalidator/ should
be updated, so that the file in question is not recognized as valid odf document
anymore. I have no idea, where to report such issue. 

@mux2005:
please report the problem to your CMS vendor (Fabasoft). As they produce invalid
ODF, their software schould be fixed asap.
Comment 7 mikhail.voytenko 2009-12-16 14:19:07 UTC 
The fix is integrated in cws fwk133.

mav->andreschnabel: The developer maintaining odfvalidator is notified.
Unfortunately, there is still no issue-tracker system related to the validator.
Comment 8 mikhail.voytenko 2009-12-16 22:57:28 UTC 
mav->tm: Please verify the issue.
Comment 9 thorsten.martens 2009-12-17 09:07:29 UTC 
checked and verified in cws fwk133 -> OK !