Fetching file sizes on the fly can lead to expired stream connection

[bayprogrammer]

I have encountered a puzzling issue where sometimes, depending on connection speed and file sizes, the zip streaming operation fails with a FileSizeIncorrectException being thrown:

File is 105596 instead of 2681571328 bytes large. Adjust `exactSize` parameter. {"exception":"[object] (ZipStream\\Exception\\FileSizeIncorrectException(code: 0): File is 105596 instead of 2681571328 bytes large. Adjust `exactSize` parameter. at .../07052025_205157/vendor/maennchen/zipstream-php/src/File.php:364)

This is caused by an issue with how we currently fetch the file sizes before passing the information on to the underlying ZipStream library (when file size prediction is requested and the sizes aren't known in advance).

Since #121 we re-use the same stream wrapper object to fetch the size of each file (if they aren't passed in by the user, which they are not in my case) as we queue them up for the underlying ZipStream library to use. If any one file then is large enough (and the connection slow enough) that it takes longer than 60 seconds to complete, then any files which are queued up to be subsequently streamed will end up with a stream wrapper where the underlying TCP connection has expired. When this happens the wrapper returns false when asked feof() and then the underlying ZipStream library is unable to read all the expected bytes, thus throwing the FileSizeIncorrectException.

We don't see this error if the connection is lazily used within the ZipStream library, such as when we disable file size prediction or else pass in known file sizes up front.

I believe I know how we can fix the issue (without introducing a regressino to #121) and I will submit a follow-up PR to fix this issue.

[bayprogrammer]

Using wget with the --limit-rate option is handy for testing these sorts of issues in development (e.g. when using MinIO). With a set of files, two of which are around 2.5 GB, I can reproduce the issue in the application I'm developing by using wget like so:

$ wget -t1 --limit-rate=20000K http://localhost:8088/route/to/zipping-action.zip

The rougly 5 GB file completes in just over a minute at that speed, which is long enough to ensure the second of the two large files will fail (since the default TCP socket connection timeout for PHP is 60 seconds (at least in my setup)).