Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


You should be able to delete all of Configurations2/..., Thumbnails/thumbnail.png, and manifest.rdf 
without any harm whatsoever, so long as the related <manifest:file-entry> elements are deleted from 
META-INF/manifest.xml.
You should probably *not* keep the settings.xml if you are creating a different content.xml file 
(just in case).

You might check on consistency of version attribute occurrences and their values.  For ODF 1.2 
documents, it is expected that there will be a consistent use of "1.2" in a variety of places.  If 
there are any missing version attributes or ones with conflicting values of "1.0" or "1.1", that 
might be a problem as well.

This is a bit trickier.  What version of ODF are you specifying in your "template" and the 
subsequent manipulations?

It could be none of these that are derailing LO.  It could be some sort of problem being caught in 
the resolution of styles, or some problem where automatic styles are involved.

SOMETHING ELSE TO TRY

When LO says the document is corrupted, do you have an option to attempt "recovery" or "repair"?  
When you exercise that option, can you save the result and reopen *that* successfully in LO ?  I 
think you have done this according to your other report.

If that works, you then need to figure out what it is that is different in the repaired one and the 
one that was declared corrupt.  Look at the manifest and the files that are present, and in the 
root element opening tags for styles.xml and content.xml.  (Notice the office:version attributes 
and any manifest:version attributes as well.)  Check to see whether automatic styles were added to 
content.xml where there are none (?) for your "corrupted" document.

 - Dennis

-----Original Message-----
From: Eric Brunel [mailto:eric.brunel@pragmadev.com] 
Sent: Tuesday, June 05, 2012 01:25
To: users@global.libreoffice.org
Subject: Re: [libreoffice-users] Document 'corrupt' for LibreOffice, opens fine with other 
OOo-based software

[ ... ]
Working from memory in order to reply quickly, I believe that there  
*IS* an ODF requirement for every stream in the package (a Zip) to  
be accounted for in META-INF/manifest.xml except the manifest  
itself, mimetype, and anything else in META-INF/ (except if it is  
meant to be encryptable).  I suspect the specifications are silent  
concerning META-INF/manifest.xml entries that have no corresponding  
stream in the Zip.  I need to confirm the facts.

Thanks for the hints. Worked on that, but no luck so far: I removed  
the references to the non-existing files and directories in the META- 
INF/manifest.xml file, but the document is still reported as corrupt.  
Then I did the reverse: keeping the existing META-INF/manifest.xml  
file and copying all the missing files and directories from the  
repaired document: LO still says the document is corrupt… I've checked  
the manifest.xml file thoroughly, and it does reference exactly all  
the files in the document, except everything in the META-INF directory  
itself and the mimetype file.

I would not be surprised if this tightening of consistency with the  
manifest is for purposes of improved detection of tampering and the  
possible incidence of a security exploit of one kind or another.   
There is a practice in security cases to avoid providing details  
since it provides too much information for someone attempting to  
craft an exploit.  That's a stretch in this case.

This was what came to my mind too…

It would be useful to soften the message to one of "There are  
inconsistencies and it is possible the document is corrupted."  The  
request for permission to attempt correction by eliminating the  
inconsistencies should be quite clear.  It would also be valuable to  
report whether there was any apparent data loss or that repair did  
not involve loss of anything critical to the document.  Encouraging  
a save-as of the repaired document to a different location would  
also be handy in restoring the confidence of the user in the  
successful effort.

Well again, telling the reason why the document is reported as corrupt  
would be a great help too. As it is now, we have to rely on wild  
guesses to figure out what to correct in the generated document, and  
that's a long and painful thing to do…

Anyway, thanks a lot again for your answers.
  - Eric -




-- 
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.