unzip error 22: invalid argument

Unfortunately I cannot share the zip file due to the contents being secure. The file was sent from a Microsoft computer, I am not sure how it was generated. however I do know that the issue is only prevalent on mine and a co-workers Mac, it should also be noted we are the only two who have updated to Catalina. Others who haven't yet updated to Catalina can open the zip with no issue.

I did send myself another zip file from a MacBook Pro (not updated to Catalina) and was able to open this zip file without issue. I did with the apple tech on the phone and this is when he advised me about Catalina not being able to unzip a 32 bit file.

Mind you I am not at all IT support so don't have much knowledge, I am just the guy that has to deal with tech problems when they happen.

if anyone else has a similar issue and has found a fix that doesn't involve a third party app, I would love to hear it.

Well, if you should happen get another one that you can post, it’d be interesting to try to reproduce it, and pull apart the (broken?) archive. But this isn’t anything related to a 32-bit app, based on what I know of zip and of its archives. I’d look at the filenames within the archive, as an initial suspicion.

I can confirm it is the filenames with extended ASCII characters (letters with more than 8 bits). I have a collection of files in a single zip -- the files with ASCII filenames uncompress fine (via cli) - those with German characters and other extended ASCII and UTF-8 charcters do not. Only GUI gives the 22 error.

Thanks. I’ll download this, and have a look at the contents. I’ve a contact or two over in zip and unzip too, if this isn’t a problem with the particular zip tool. (Do you happen know the identity and version of that tool, over on Windows?)

Sorry, don't have a clue what they've used to zip this particular file but I've had the same problem with a file sent to me by a "known contact" and I can ask her to figure out what zip-tool (id and version) she's using, zip some stuff for me and post that file here too if if you think that'll help.

So, here are two files (password is 1510), one that I can unzip and one that I can't. Both files should contain the same file only named differently (one with Swedish characters and one without).

working.zip

not-working.zip

These files were made with 7zip version 18.05 on Windows and I use Archive Utility version 10.15 on my Mac.

I hope this helps determining what the problem might be.

That Caslau.zip? Two gigabytes is going to take a while to download here among the internet backwaters. I'll have a look at Caslau.zip later; after it arrives.

As for the not-working.zip file, that's readable with the command line unzip V6.0, on a test-configured box running High Sierra. This using the stock unzip from High Sierra. There's presently no-configured Catalina box readily available to check that.

$ unzip not-working.zip
Archive:  not-working.zip
[not-working.zip] ARIVAB kind Logga åäö.pdf password: 1510
  inflating: ARIVAB kind Logga åäö.pdf  
$ ls "ARIVAB kind Logga åäö.pdf"
ARIVAB kind Logga åäö.pdf
$ file "ARIVAB kind Logga åäö.pdf"
ARIVAB kind Logga åäö.pdf: PDF document, version 1.4
$ 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 9.0.0 (clang-900.0.31) for Unix Mac OS X on Oct  6 2017
...
$ whereis zip
/usr/bin/zip
$ 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%
$ 
$ 

Looks like this might be a known limit of zip, which is what these archives are being created as, and 7-Zip is allowing something into the zip archive file names that it (arguably) probably should not. There might be a workaround, but for the creator of the zip archives. See the following URL, and see the -mcu stuff below.

https://sourceforge.net/p/p7zip/discussion/383044/thread/18fe4771/

Caslau.zip unpacks with the command line, as well:

$ zipinfo Caslau.zip     
Archive:  Caslau.zip
Zip file size: 2255415099 bytes, number of entries: 348
drwxa--     2.0 fat        0 b- stor 19-May-06 01:11 Czech Cem_Caslau/
-rw-a--     2.0 fat  6633597 b- defX 17-Sep-17 11:39 Czech Cem_Caslau/20170917_113951.jpg
-rw-a--     2.0 fat  6431121 b- defX 17-Sep-17 12:20 Czech Cem_Caslau/20170917_121957.jpg
...
-rw-a--     2.0 fat  6184800 b- defX 17-Sep-17 12:02 Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120216.jpg
-rw-a--     2.0 fat  7738339 b- defX 17-Sep-17 12:02 Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120220.jpg
-rw-a--     2.0 fat  8756593 b- defX 17-Sep-17 12:02 Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120227.jpg
...
-rw-a--     2.0 fat  6808250 b- defX 17-Sep-17 12:16 Czech Cem_Caslau/_u_20170917_121653.jpg
348 files, 2263625977 bytes uncompressed, 2255356879 bytes compressed:  0.4%
$ unzip Caslau.zip  "Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120220.jpg"
Archive:  Caslau.zip
  inflating: Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120220.jpg  
$ file "Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120220.jpg"
Czech Cem_Caslau/Friedländer Josef, Gustav_20170917_120220.jpg: JPEG image data, Exif standard: [TIFF image data, little-endian, direntries=16], baseline, precision 8, 3096x4128, frames 3
$ 

I'm getting an encoding error in some contexts, though:

open  "Czech Cem_Caslau/Friedl%E4nder Josef, Gustav_20170917_120220.jpg"

Looking at the not-working.zip in a directory listing, I'm seeing the same %E4 encoding in the unpacked filename.

That's almost certainly a z

In summary, it's possible to unpack the zip archives using the command line, which gets you where you want, if not entirely the way you want. I'm going to have to dig into the contents of the zip archives and the zip design docs in some detail and maybe into the 7z tool to see more about what's going on here, but that's something that won't effect your ability to read these archives.

Yes, I know, the restored filenames will be wrong. A script to fix that is certainly feasible.

7-Zip 7za (16.02) on macOS sees the same issue with unpacking the file names, so no help there.

With the Windows 7z/7za tool creating this zip archive, maybe switching from the default -mcu=off to -mcu=on might help? This selects UTF-8 filenames. This -mcu=on is discussed in the URL above. There's no Windows box handy to test that here, though.

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%

So in short, no there is no fix rn. The workaround is too time consuming for me and I am not about to play hackerman with command line to to a simple extraction.

Much easier for me to unzip it on my windows desktop and then copy files via usb. :DDD

The bug is in the Archive Utility provided with MacOS Catalina.

I have used "The Unarchiver" app downloaded from the App Store. Worked like a charm!

It asks you during unarchiving to choose the encoding for the characters causing the Archive Utility to crash.

Hi, I finally solve this issue with ditto, the command line is

ditto -x -k zip_path unzip_destination

Please refer to this blog for details: http://marckerr.com/using-ditto-to-create-and-extract-archives/

Thanks

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.

@MrHoffman, I just caught up on the thread, and yes this is exactly what is happening to me. I cannot unzip anything that turned into zip as the app immediately crashes. Do you have any suggestions on what to do moving forward (go SLOW, I am not good at this) TIA

Mackytack wrote:

@MrHoffman, I just caught up on the thread, and yes this is exactly what is happening to me. I cannot unzip anything that turned into zip as the app immediately crashes. Do you have any suggestions on what to do moving forward (go SLOW, I am not good at this) TIA

See previous discussions of using ditto, and of not populating zips with unhandled characters.