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

2012-09-24 Thread Fridrich Strba
OK, I pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=5db7ac239278634c39cbb15f0173db0524b5dcd6 which *I* consider as a good solution. I checked around other unzip implementations and it does not look like they consider the timestamp differences as a brokenness. Cheers F.

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

2012-09-24 Thread Michael Meeks
On Mon, 2012-09-24 at 09:30 +0200, Fridrich Strba wrote: OK, I pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=5db7ac239278634c39cbb15f0173db0524b5dcd6 which *I* consider as a good solution. I checked around other unzip implementations and it does not look like they

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

2012-09-21 Thread Michael Meeks
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

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

2012-09-21 Thread Fridrich Strba
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

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

2012-09-21 Thread Fridrich Strba
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