You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is mz_zip_entry_read_close suitable with non-NULL args? #840
However, the comment only speaks of compression which is not the case for a read-only archive.
Hence, we observed that the stream manipulation in mz_zip_entry_read_close lead to corrupt streams for reads of subsequent enries (mz_zip_entry_read_header fails on the MZ_ZIP_MAGIC_CENTRALHEADER check).
Hence, we observed that the stream manipulation in mz_zip_entry_read_close lead to corrupt streams for reads of subsequent enries (mz_zip_entry_read_header fails on the MZ_ZIP_MAGIC_CENTRALHEADER check).
I'm not sure what the particulars of your zip are. Is it using data descriptors? Can you attach it?
Actually, it's the ZIP file Aufschluesse.zip within the provided ZIP archive which caused the issue for us.
Sorry, misread the message.
unzip thinks Aufschluesse.zip is ok.
$ unzip -t Aufschluesse.zip
Archive: Aufschluesse.zip
testing: Aufschluesse.csv OK
testing: Aufschluss_Bereiche.csv OK
testing: Baugrundmodell_Bereiche.csv OK
testing: Baugrundmodell_Definition.csv OK
testing: Baugrundmodell_Eigenschaften.csv OK
testing: Bodenwerte_Definition.csv OK
testing: Erdarbeiten_DIN_18300_Bereiche.csv OK
testing: Erdarbeiten_DIN_18300_Eigenschaften.csv OK
testing: Erdarbeiten_DIN18300_Definition.csv OK
testing: fachmodell_baugrund.xml OK
testing: Farben.csv OK
testing: Grundwasser_Definition.csv OK
testing: Grundwasser_Staende.csv OK
testing: Konsistenz_Bereiche.csv OK
testing: Konsistenzen.csv OK
testing: Proben.csv OK
testing: Proben_Messwerte.csv OK
testing: Probenarten.csv OK
testing: Schnitte.csv OK
No errors detected in compressed data of Aufschluesse.zip.
Here is what the metatdata looks like. Only thing that stands out is the entries are streamed. Ignore the messages about the unexpected Extra Field 'Extended Timestamp'.
Sorry for the confusion: The actual file is Aufschluesse.zip. I zipped it additionally to avoid any accidentally repacking when uploading to GitHub. So again: Unpack Aufschluesse.zip from Issue840.zip and handle Aufschluesse.zip via minizip-ng. Hence, it is not about zip in zip. It's all about file Aufschluesse.zip.
Activity
nmoinvaz commentedon Mar 5, 2025
That comment should say decompression not compression.
nmoinvaz commentedon Mar 5, 2025
I'm not sure what the particulars of your zip are. Is it using data descriptors? Can you attach it?
thbeu commentedon Mar 6, 2025
Thanks for replying. Please find the zip archive attached. It is the archive file Aufschluesse.zip within the attached file: Issue840.zip
pmqs commentedon Mar 9, 2025
Here is a readout on the structure of Issue840.zip. Nothing looks out of the ordinary
Similarly,
unzipthionks all is okthbeu commentedon Mar 9, 2025
Actually, it's the ZIP file Aufschluesse.zip within the provided ZIP archive which caused the issue for us.
pmqs commentedon Mar 9, 2025
Sorry, misread the message.
unzipthinksAufschluesse.zipis ok.Here is what the metatdata looks like. Only thing that stands out is the entries are streamed. Ignore the messages about the unexpected
Extra Field 'Extended Timestamp'.nmoinvaz commentedon Mar 10, 2025
Zips in zips are not compatible with data descriptors, you will have to disable data descriptors.
thbeu commentedon Mar 10, 2025
Sorry for the confusion: The actual file is Aufschluesse.zip. I zipped it additionally to avoid any accidentally repacking when uploading to GitHub. So again: Unpack Aufschluesse.zip from Issue840.zip and handle Aufschluesse.zip via minizip-ng. Hence, it is not about zip in zip. It's all about file Aufschluesse.zip.
thbeu commentedon Mar 10, 2025
OK. Might that be the cause of the observed issue?
nmoinvaz commentedon Mar 10, 2025
Yes turn off data descriptors and it should work.
thbeu commentedon Mar 11, 2025
It's not in our hand how the ZIP file is created. We need to handle both ZIP files with
MZ_ZIP_FLAG_DATA_DESCRIPTORset and not set.To me it looks like a library issue since
mz_zip_entry_read_closemust not be called with non-NULL args on data descriptor entries.zlib-ng#840 Restore stream position after reading data descriptor in …
zlib-ng#840 Restore stream position after reading data descriptor in …