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


Ah, the timestamp actually is not a time_t, they are two shorts (2 bytes
long) from which the first one gives the modification time and the second the modification date. So 
the difference can be some seconds. It is possible that some zip implementations dump the 
timestamps of the directory creation in the cdir entries and timestamps of the file addition to the 
local file header. So, the timestamp in the cdir should never be smaller then in local file header. 
Maybe it is good test of corruption to check that instead of identity.

F.

Sent from Samsung Mobile

Fridrich Strba <fridrich.strba@graduateinstitute.ch> wrote:

First of all, the timestamps in that file are really bogus, I cannot
imagine an ooxml file produces in 2004, only if the machine has wrongly
set the clock.

Second, when working on a zip implementation for libcdr and for the LO
shell extension, I realized that the timestamps were never really good
to check for consistency with the local entry header and the central
directory entry. I think that the best would be to compare them by crc.
And one has to take into account that crc can be 0 and then the real crc
is to be found just after the stream in a structure that is to be found
by a magic and there, it is possible not to have even the real
compressed and uncompressed sizes in the local entry header.

My proposal would be to be much less strict in what we consider as
corrupted for the zip-based documents. Instead check things that are for
sure to be the same in the two structs, like the encryption, crc32 and
compression type.

Cheers

F.

On 21/09/12 22:36, Michael Meeks wrote:
Hi guys,

I've not worked out where these odd ZIP container inconsistencies are
coming from, but ... since people appear to see them, presumably it's
worth being more accepting:

Not 100% confident about this, the more I read SfxMedium & friends, the
more convinced I am we need some root+branch stream re-work, but hey.

I'd love someone expert in writerfilter to review it, and (IMHO) we
need to do the same work for PPTX / XLSX to ensure that we can prompt
and enter the Repair mode. Then I think we need to undo the hack that is
the fix for bug#54609 :-)

Thoughts appreciated.

Michael.



_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



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.