When Zip64 was first introduced the default strategy was to usezip64 extensions if the size of the entry was known and required it, or the size was not known.  This was the safest way of handling large files it seemed as it wasn't possible to end up with an entry and all the data written only to discover at the end that the header was not usable for an entry that turned out to need Zip64.

There were complaints however from people who found they couldn't open there archives with XP's build in compression as it could not handle Zip64.  The library was changed adding a setting which defaulted to not using Zip64.

After spending a fair while trying to help someone recently with problems with large files only to discover that this was the cause I have decided to go back to the original strategy as the library will not (by default) occasionally blow up.  Its better to get a valid archive and sometimes not see it easily than to blow up!

The setting is still there for now but the best method of getting optimal results is to set the size of the entry before it is added.  For streams that dont support seeking Zip64 is the best default strategy I think.

The cleanest and best solution is to set the size for each entry that is added as there is no confusion then!