https://bugs.documentfoundation.org/show_bug.cgi?id=162944

Michael Stahl (allotropia) <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|Calc                        |filters and storage
         Resolution|---                         |NOTABUG

--- Comment #7 from Michael Stahl (allotropia) <[email protected]> ---
the file does look invalid to me, 64-bit data descriptor but no zip64 extra
field:

      4.3.9.2 When compressing files, compressed and uncompressed sizes 
      SHOULD be stored in ZIP64 format (as 8 byte values) when a 
      file's size exceeds 0xFFFFFFFF.   However ZIP64 format MAY be 
      used regardless of the size of a file.  When extracting, if 
      the zip64 extended information extra field is present for 
      the file the compressed and uncompressed sizes will be 8
      byte values.  

and in any case, the file is opened by LO in "Repair" mode, so i think that's
good enough, resolving NOTABUG for now.

(the Repair mode appears to "guess" if it's zip64 based on a following
signature)

POI would be using Apache Commons-Compress; the code to write the data
descriptor is
in
https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.java

    protected void writeDataDescriptor(final ZipArchiveEntry ze) throws
IOException {
        if (!usesDataDescriptor(ze.getMethod(), false)) {
            return;
        }
        writeCounted(DD_SIG);
        writeCounted(ZipLong.getBytes(ze.getCrc()));
        if (!hasZip64Extra(ze)) {
            writeCounted(ZipLong.getBytes(ze.getCompressedSize()));
            writeCounted(ZipLong.getBytes(ze.getSize()));
        } else {
            writeCounted(ZipEightByteInteger.getBytes(ze.getCompressedSize()));
            writeCounted(ZipEightByteInteger.getBytes(ze.getSize()));
        }
    }

contains the obvious check that there is a Zip64 extra field - which the
attached file doesn't have.

this has been substantially changed since 2011 when Zip64 support was
introduced:

https://issues.apache.org/jira/browse/COMPRESS-150

really not clear how this file was produced...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to