Jason

Thanks for the replies! The bug here definitely lies within info-zip's zip, and I did submit a bug report to info-zip a few days ago. And yeah there's nothing special about pv here, any real piping would trigger this bug.

I managed to reproduce this by zipping 7-Zip's Linux release. I have both zip3.0 and zip3.1 in my PATH and zip3.1 is referred to as zip31. Command used to produce the zip: zip31 -r -q -y - 7zip_linux | pv -trb > 7zip.zip What happens when 7zz tries to list its contents: 7zz l 7zip.zip 7-Zip (z) 21.02 alpha (x64) : Copyright (c) 1999-2021 Igor Pavlov : 2021-05-06 compiler: 7.4.0 GCC 7.4.0 64-bit locale=en_US.utf8 UTF8=+ use-UTF8=+ wchar_t=32-bit Files=64-bit Threads:32, Intel(R) Xeon(R) Gold 6242...

I'll try to make one now. Should be able to produce one that's 1MB or less

I see... On another note, it seems that 7-zip doesn't correctly read streamed zip archives created by info-zip, while unzip can read them with no problem. I first noticed this issue when Peazip and gnome archive manager, which use 7-zip on the backend, don't open them correctly. This is very reproducible if you use zip31d by info-zip, which you can find on https://github.com/zorba-the-geek/zip31d or ftp://ftp.info-zip.org/pub/infozip/beta/ zip31d is a beta/release candidate that improves zip's ability...

I see... On another note, it seems that 7-zip doesn't correctly read streamed zip archives created by info-zip, while unzip can read them with no problem. I first noticed this issue when Peazip and gnome archive manager, which use 7-zip on the backend, don't open them correctly. This is very reproducible if you use zip31d by info-zip, which you can find on https://github.com/zorba-the-geek/zip31d or ftp://ftp.info-zip.org/pub/infozip/beta/ zip31d is a beta/release candidate that improves zip's ability...

Hi Igor, Thanks for the reply! The one file limitation of xz is why I don't want to use it... Essentially I want to create large archives that are easy to index (7z, zip, etc.) and upload them without using too much disk space.

Possible support for disk archive (DAR)?

Hi, Is it possible that compressing to 7z format will be able to support non-seekable destination (e.g. remote directory, stdout)? I want to compress some big files and upload them to cloud but don't have much disk space left. If it's not possible to avoid seeking entirely, is it possible to avoid it partially? For example, create two volumes headed to two destinations where seek is required only on the second (hopefully smaller) volume? Thanks!