<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body >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.<div> </div><div>F. Sent from Samsung Mobile </div> 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 > </body>