Can you share any details on how the file was created?
That could be mean the file has got corrupted while downloading, or it has the corruption cooked into the original file.
That output suggests there is more wrong with your zip file than just the Total Number of Disks issue.
Installprivlib and installarchlib points to the Updates directoryħ-Zip 16.02 : Copyright (c) 1999-2016 Igor Pavlov : Library/Perl/Updates/ comes before system perl directories USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL Libc=, so=dylib, useshrplib=true, libperl=libperl.dylibĭlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' 'Ĭccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -fstack-protector'Ĭharacteristics of this binary (from libperl):Ĭompile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS Ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 Intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678ĭ_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 Use64bitint=define, use64bitall=define, uselongdouble=undefĬc='cc', ccflags =' -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector',Ĭppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector'Ĭcversion='', gccversion='4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc-selector-opts)', gccosandvers='' Useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef Useithreads=define, usemultiplicity=define Hint=recommended, useposix=true, d_sigaction=define Osname=darwin, osvers=19.0, archname=darwin-thread-multi-2level Summary of my perl5 (revision 5 version 18 subversion 4) configuration: It tried zipdetails but after 12 hours I cancelled it. This feature, but thanks for considering! I don't know if the above is enough of a powerful argument for adding
Qualified myself to submit a patch for this. Really useful feature for lots of people. Thinkt that to be able to handle these "corrupted" files would be a I totally understand that this whole mess is Apple's fault. Would love to be able to do this with Info-Zip directly.
What we do is run 7zip on Windows orĪpple's "ditto" on macOS in a VM. Right now I am not aware of a tool to successfully uncompress theseĭefect files natively on Linux. I have also tried submitting feedback to Apple To convince these people that they should not use the Apple Finder toĬompress their files. I work for a large film festival where we receive lots of submissionsĬompressed into multi-gigabyte zip files (10-150 GB) compressed withĪpple tools. That Macs and Apple tools are so widely used. The problem is not so much in creating compliant zip files myself, but > on the list of UnZip features to be added. > very powerful argument (and/or a suitable patch), I'd rank it pretty low > results from using a small-file program on a large file, but without a
> It might be possible to get UnZip to try to unravel the mess which