unzip error 22: invalid argument

There are various schemes for Extended ASCII and character sets with eight or more bits lit and that aren’t UTF-8 or UTF-16 and Unicode, and that’s all an increasingly dead-end for portability, outside of maybe existing ISO Latin 1 ISO 8859-1 use. Microsoft Windows had (has?) its own extensions to ISO Latin 1.

Seems the GUI unzip tool has a problem (“limitation”?) with the character encoding in the filename.

Or the archive-generating tool (whatever tool and version that is, here) isn’t tagging the encoding correctly.

Package up the details and a reproducer and a link to this thread and lob some feedback at Apple, or call Apple Support with the details, or log a bug directly if you should have developer access to the bug reporter.

Definitely looks to be a known mess.

The archive appears technically corrupt as created, whether something has tightened in Catalina or not.

And it does appear that something has tightened.

An older macOS version booted as a guest or booted on an external device would be another workaround.

Based on another report of this problem, it seems ditto and unarchiver might be other potential workarounds.

The local High Sierra testing system is HFS+ and not APFS, which is probably why I'm not seeing this.

Which implies an external HFS+ disk might be another workaround, albeit with bad characters.

isuru291 wrote:

rename and then unzip using terminal. It works for me.

The command line unzip works fine for many zip archives. The command line unzip won’t work so well with the filename characters found in some of these zip archives. I’ve previously verified the unzip error here in this thread on High Sierra; check the earlier replies.

It is NOT just Chinese Characters. All zipped files within the zip that have either extended ASCII letters or UTF in the filenames will not expand - at least if one uses the cli to unzip -- then the filenames with only ASCII in the names DO expand and are usable.

I have used the apple feedback link listed below.

32-bit apps and 32-bit archives are entirely different topics.

zip archives are transportable across a wide variety of platforms, and zip and unzip was 32-bit until zip 3 / unzip 6. (I’m still playing Whac-A-Mole with some folks running older versions, too.)

If the “real” unzip tool is hitting this crash, then there’s a bug or incompatibility in whatever tool compressed the file, or there’s a bug or limit in unzip, or a hole in the zip archive design. And it’ll still be necessary to read the older 32-bit zip archives for the foreseeable future, too.

Do you have an example zip archive file you can post somewhere? Folks here can take a look, and maybe this then gets identified and maybe then involves the Info-Zip folks? Also details on what OS and tool and command was used to generate it?

Based solely on what’s been posted, I’m wondering if there’s a filename-encoding incompatibility somewhere. Which would be entirely unrelated to 32-bit apps.

Thanks for your insights MrHoffman, unfortunately I'm not getting the same results. Could it be related to that I'm running Catalina? I'm pretty sure these problems started after I upgraded so..

➜  zipfiles unzip not-working.zip
Archive:  not-working.zip
[not-working.zip] ARIVAB kind Logga ���.pdf password:
error:  cannot create ARIVAB kind Logga ���.pdf
        Illegal byte sequence
➜  zipfiles unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.32.4) (-macos10.15-objc-selector-opts) for Unix Mac OS X on Aug 24 2019.

UnZip special compilation options:
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        VMS_TEXT_CONV
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]
➜  zipfiles zipinfo not-working.zip
Archive:  not-working.zip
Zip file size: 56889 bytes, number of entries: 1
-rw-a--     6.3 fat    77679 Bx defN 19-Nov-07 10:24 ARIVAB kind Logga ���.pdf
1 file, 77679 bytes uncompressed, 56693 bytes compressed:  27.0%

hl1010 wrote:

Command line unzip worked

Please see the earlier discussions of the issues with the commands line unzip and files with the Windows character encoding.

If command line unzip worked and the filenames were restored as expected, then you probably have a yet different issue with the contents of the zip archives.

After testing, I found that it was under windows, and the file contained the Chinese, this problem occurred when unzip. I unzipped it with catalina own zip tool.

I could unzip half the files in my zip file. Those with only ASCII in the file name worked. Those with extended ASCII an 'ä' - so 32 bit windows is not the only problem.

It doesn't have to be that complicated.

You can use the third unzip tool, such as eZip

Very smooth :)

rename and then unzip using terminal. It works for me.

galking wrote:

After testing, I found that it was under windows, and the file contained the Chinese, this problem occurred when unzip. I unzipped it with catalina own zip tool.

Not sure what that sequence is, but guessing there’s an encoding problem with the Catalina GUI tools that are providing unzip support on Catalina, and you’ll want to log some feedback with Apple with as much detail on the character encoding and the rest of a reproducer as can be available.

Look at https://docs.microsoft.com/en-us/windows/win32/intl/character-sets-used-in-file-names File names are handled differently on FAT FAT32 and NTFS in Windows.

Apparently, Windows handles non-Roman characters in file and path names on different file formats. This is probably the root of the problem. However, I don't think that Catalina has GUI zip/unzip tool. Nothing show up when I search for programs using LaunchPad. When I run unzip -v, I receive a message that I'm using InfoZip 6.00. From the dates I suspect that that came with Catalina. Are you saying that it works from CLI but not with GUI. By GUI, do you mean double clicking on file in finder. If so, do Get Info on the file and see what the default tool is. If the default tool is a third party tool that wasn't from Apple, you may need to change the default tool. That's what MrHoffman was referring to.

Using the which command for zip and unzip commands in the CLI will tell you which program the shell is looking at zip -v and unzip -v will give you information on the source of this program.

The fact that a program is 64 bit does not mean that it will run correctly in Catalina. If you are using old third party programs, strange things can happen.

If you have a method that works with CLI, list what you entered as a command and use the zip -v and unzip -v to determine which version the CLI is using. By the way, unzip -v also gives the name of the person to send bug reports to. zip and unzip are not supplied by Apple but by the UNIX community.

macalienz wrote:

Same issue. I can't unzip many folders since I installed Catalina (iMac retina 4K, 21,5 inch, 2017 - MacOs Catalina 10.15.3). I can open the same folders with my old iMac (20 inch, late 2007 - MacOs El Capitan 10.11.6!).

Please see the earlier discussions for the variations, and for the work-arounds.

Log some feedback for Apple too as those reporte seem to work rather like votes, rather than adding the me-toos here and which may or may not get noticed by Apple.

215HurriKaneDJ wrote:

I get the error 22: invalid argument when trying to unpack zip files that I downloaded from an application called mediafire.

Contact the Mediafire support folks, and apprise them of the error, and a pointer to this thread. Unless you want to read through this thread. And given whatever this is is clearly failing on Catalina, there may well other problems awaiting with this kit.