Does writeDAT need to determine the file size to ensure that zip32 or zip64 is used?

[abo-H]

I am confused. In Zip64Impl, when the zip compression version number is 4.5, if the zip64 extension does not exist and the compressed file size is less than 4GB, in this method int writeDAT(Entry entry) throws IOException, 8 bytes will be used to represent the file size.
Does this comply with the zip standard specification? I did not see in the zip standard document that zip4.5 version must use the zip64 format Data Descriptor extension.
In other words, is it necessary to make a judgment here? To use the zip32 format or zip64 format Data Descriptor?

    /**
     * Write Data Descriptor
     */
    int writeDAT(Entry entry) throws IOException {
        written = 0;
        writeInt(PK0708);                        // data descriptor signature "PK\007\008"
        writeInt(entry.crc);                     // crc-32
        writeLong(entry.compressedSize);         // compressed size (zip64)
        writeLong(entry.size);                   // uncompressed size (zip64)
        return written;
    }

The reason I'm confused by this is that when there is only version 4.5 in a zip, the file size is less than 4GB and there is no zip64 extension.
Other parsing libraries cannot parse the data descripte area correctly (treating it as zip32 or zip64?), and I'm not sure if this is a problem with the other zip parsing libraries or writeDAT's problem?

[rzymek]

I don't remember the details, as I did write this 5 years ago. Keep in mind that this is a zip64 implementation made specifically for MS Excel to understand. It's not meant to be a general Zip64 library. Zip64 spec is quite vague, as far as I remember and this implementation strives to produce xlsx (zipped dirs with xmls) that are very similar to what MS Excel produces.

[abo-H]

I don't remember the details, as I did write this 5 years ago. Keep in mind that this is a zip64 implementation made specifically for MS Excel to understand. It's not meant to be a general Zip64 library. Zip64 spec is quite vague, as far as I remember and this implementation strives to produce xlsx (zipped dirs with xmls) that are very similar to what MS Excel produces.

Yes, the zip64 standard is indeed vague, but it looks like MS Excel does it this way. It sounds crazy to have different zip implementations compatible with different zip parsing libraries.🤯