t/22_deflated_dir.t fails with bad extra-field entry on some Linux x86_64 systems

[stuart-little]

I'm puzzling over the following. I'm testing the latest version at the time of this writing, namely 1.68, on two systems (both Linux x86_64, one Arch and one Ubuntu 20.04).

On Arch the tests (cpanm --test-only Archive::Zip) fail with this. That's the full log, but the gist of it is

#   Failed test 'Wrote file - test write plain'
#   at t/22_deflated_dir.t line 20.
# Got result:
# Archive:  /tmp/testout-sW6M5.zip
#     testing: META-INF/               bad extra-field entry:
#       EF block length (0 bytes) invalid (< 4)

On the other hand, the Ubuntu system tests fine..

[stuart-little]

Although both systems have unzip 6.00, there must be some differences in how it's compiled. When I get this source and build it on the failing system, for instance, cpanm --test-only Archive::Zip using the new unzip works fine.

[pmqs]

That test appears to just read a jar file into memory & write out out again.

If you have the time can you try editing the file t/22_deflated_dir.t Add the file option to the azwok call -- that will get it to save the output to a named file

azwok($zip, name => 'Wrote file', file => "test22.zip");

under the hood it looks like azwok saves the zip file in two different ways, so we need to get each saved

edit t/common.pm and change this line

$ok &&= ok($fh = azopen($file), "$name - open piped handle");

to

$ok &&= ok($fh = azopen("pipe-" . $file), "$name - open piped handle");

and this line

$ok &&= azok($zip->writeToFileNamed($file), "$name - write plain");

to

$ok &&= azok($zip->writeToFileNamed("plain-" . $file), "$name - write plain");

run

make test TEST_FILES=t/22_deflated_dir.t

that should leave these two files pipe-test22.zip and plain-test22.zip.

On my Ubuntu setup the two file are identical and unzip -t doesn't see any problems

$ unzip -t pipe-test22.zip
Archive:  pipe-test22.zip
    testing: META-INF/                OK
    testing: META-INF/MANIFEST.MF     OK
    testing: file                     OK
No errors detected in compressed data of pipe-test22.zip.

If you can reproduce the error can you post the zip files created please?

[stuart-little]

Thanks for the guidance. I am getting the same error, one one system (Arch) but not the other (Ubuntu). So this confirms my earlier report.

First, the files: plain and pipe.

Secondly, they are indeed identical, as checked with diff (which returns no error and an $? of 0).

Thirdly, on Arch:

$ unzip -t ~/Dropbox/Public/plain-test22.zip
Archive:  $HOME/Dropbox/Public/plain-test22.zip
    testing: META-INF/               bad extra-field entry:
      EF block length (0 bytes) invalid (< 4)
    testing: META-INF/MANIFEST.MF     OK
    testing: file                     OK
At least one error was detected in $HOME/Dropbox/Public/plain-test22.zip.

On the other hand, on Ubuntu:

$ unzip -t ~/Dropbox/Public/plain-test22.zip                                     Archive:  $HOME/Dropbox/Public/plain-test22.zip
    testing: META-INF/                OK
    testing: META-INF/MANIFEST.MF     OK 
    testing: file                     OK             
No errors detected in compressed data of $HOME/Dropbox/Public/plain-test22.zip.

(the computers share the Dropbox folder; they're checking the same file)

[pmqs]

I see what the Arch version of unzip is complaining about, but it is not an error. Jar files contain a field near the start of the zipfile that allow them to operate as executable files on Unix/Linux platforms.

Below is a dump of the start of plain-test22.zip

0000 LOCAL HEADER #1       04034B50
0004 Extract Zip Spec      14 '2.0'
0005 Extract OS            00 'MS-DOS'
0006 General Purpose Flag  0800
     [Bit 11]              1 'Language Encoding'
0008 Compression Method    0000 'Stored'
000A Last Mod Time         46CFB0D3 'Mon Jun 15 22:06:38 2015'
000E CRC                   00000000
0012 Compressed Length     00000000
0016 Uncompressed Length   00000000
001A Filename Length       0009
001C Extra Length          0004
001E Filename              'META-INF/'
0027 Extra ID #0001        CAFE 'Java Executable'
0029   Length              0000

The error

    testing: META-INF/               bad extra-field entry:
      EF block length (0 bytes) invalid (< 4)

is complaining that the length field at offset 0029 is zero.

Bottom line is the Arch version of unzip appears to be well out of date.

Just out of interest, could you run unzip -t t/data/jar.zip on Arch to see what it thinks of the original jar file?

[stuart-little]

I see what the Arch version of unzip is complaining about, but it is not an error. Jar files contain a field near the start of the zipfile that allow them to operate as executable files on Unix/Linux platforms.

Oh, certainly not a big deal, but it was enough of an error to trip up cpanm every time I'd build all of my modules automatically with perlbrew after a new install. That's how I noticed anyway: on this one machine I kept having to install Archive::Zip (and other stuff downstream from it, like Firefox::Marionette) manually.

Bottom line is the Arch version of unzip appears to be well out of date.

I agree that if there's a problem here, it's the way Arch packages unzip. In fact, I've reported the problem there, which is likely the right forum.

Just out of interest, could you run unzip -t t/data/jar.zip on Arch to see what it thinks of the original jar file?

Same behavior:

$ unzip -t t/data/jar.zip
Archive:  t/data/jar.zip
    testing: META-INF/               bad extra-field entry:
      EF block length (0 bytes) invalid (< 4)
    testing: META-INF/MANIFEST.MF     OK
    testing: file                     OK
At least one error was detected in t/data/jar.zip.

[stuart-little]

In fact, in light of the nature of the problem, I think maybe it's safe to close this, right?

I'm glad I asked, since you guided me through getting a test file that I could then provide the Arch folks with, but I agree that the problem's not really with Archive::Zip.

[pmqs]

Yes, think you should close it.

[stuart-little]

Done, and thank you!