Re: [REVIEW-3-6] fdo#49819 - slightly inconsistent docx files causing grief ...
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 consider the timestamp > differences as a brokenness. Right - it seems a bit paranoid; particularly with no 'repair' fallback. In general, I think the right approach is to ignore this inconsistency - particuarly if Microsoft/other-common-impl. is creating this sort of nonsense timestampage. Lets get that into -3-6 to nail the issue. Thanks :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW-3-6] fdo#49819 - slightly inconsistent docx files causing grief ...
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. 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 > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 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 > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW-3-6] fdo#49819 - slightly inconsistent docx files causing grief ...
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 > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
