Re: [REVIEW-3-6] fdo#49819 - slightly inconsistent docx files causing grief ...

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