Test suite fails on older FreeBSD systems (1.68)

[eserte]

On my freebsd 10 and 9 systems:

PERL_DL_NONLAZY=1 "/usr/perl5.20.1Dp/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
# Calling "unzip" resulted in:
# usage: unzip [-aCcfjLlnopqtuvZ1] [-d dir] [-x pattern] zipfile
# Exit value 256
t/01_init.t ................... ok

#   Failed test at t/02_main.t line 107.
# Got result:
# Archive:  /var/tmp/cpansmoker-1023/2020031219/testout-ZTyFT.zip
# unzip: Invalid central directory signature
# Exit value 256
... (more of these) ...
...
#   Failed test 'write and test zip file - test write piped'
#   at t/21_zip64.t line 112.
# Got result:
# Archive:  /var/tmp/cpansmoker-1023/2020031219/testout-Z65nZ.zip
# unzip: Invalid central directory signature
# Exit value 256
# Expected (more or less) result:
# Archive:  t/data/zip64.zip
#     testing: README	 OK
# No errors detected in compressed data of t/data/zip64.zip.
# Exit value 0
...

[farblos]

Thanks, have been monitoring these already on CPAN testers. Seems that FreeBSD's light-weight unzip is rather unhappy with the zip files A::Z generates, at least for FreeBSD 9 and 10.

@pmqs, @redhotpenguin: Before I invest any time in following up on these, does the search

Archive::Zip ( "FreeBSD 9" OR "FreeBSD 10" ) unzip

ring any bell? Should we probably skip all "unzip -t" tests on FreeBSD 9/10?

[pmqs]

@farblos the test is failing with a Zip64 file that A::Z has created. Zip64 is still quite new in A::Z, so there may be some issues to be fixed (or it may just be that unzip on FreeBSD has its own issues). I don't have FreeBSD available at the moment to check.

For reference, here is a dump of the zip file that the test is creating. Nothing is jumping out at me after a very quick scan. I'll try to get some time to take a closer look at it.

0000 LOCAL HEADER #1       04034B50
0004 Extract Zip Spec      2D '4.5'
0005 Extract OS            00 'MS-DOS'
0006 General Purpose Flag  0000
0008 Compression Method    0000 'Stored'
000A Last Mod Time         5070B1EC 'Mon Mar 16 22:15:24 2020'
000E CRC                   00000000
0012 Compressed Length     FFFFFFFF
0016 Uncompressed Length   FFFFFFFF
001A Filename Length       0013
001C Extra Length          0014
001E Filename              'testdir/cF0qHwR_zs/'
0031 Extra ID #0001        0001 'ZIP64'
0033   Length              0010
0035   Uncompressed Size   0000000000000000
003D   Compressed Size     0000000000000000

0045 CENTRAL HEADER #1     02014B50
0049 Created Zip Spec      14 '2.0'
004A Created OS            03 'Unix'
004B Extract Zip Spec      2D '4.5'
004C Extract OS            00 'MS-DOS'
004D General Purpose Flag  0000
004F Compression Method    0000 'Stored'
0051 Last Mod Time         5070B1EC 'Mon Mar 16 22:15:24 2020'
0055 CRC                   00000000
0059 Compressed Length     00000000
005D Uncompressed Length   00000000
0061 Filename Length       0013
0063 Extra Length          000C
0065 Comment Length        0000
0067 Disk Start            0000
0069 Int File Attributes   0000
     [Bit 0]               0 'Binary Data'
006B Ext File Attributes   41FD0010
     [Bit 4]               Directory
006F Local Header Offset   FFFFFFFF
0073 Filename              'testdir/cF0qHwR_zs/'
0086 Extra ID #0001        0001 'ZIP64'
0088   Length              0008
008A   Offset to Local Dir 0000000000000000

0092 ZIP64 END CENTRAL DIR 06064B50
     RECORD
0096 Size of record        000000000000002C
009E Created Zip Spec      2D '4.5'
009F Created OS            00 'MS-DOS'
00A0 Extract Zip Spec      2D '4.5'
00A1 Extract OS            00 'MS-DOS'
00A2 Number of this disk   00000000
00A6 Central Dir Disk no   00000000
00AA Entries in this disk  0000000000000001
00B2 Total Entries         0000000000000001
00BA Size of Central Dir   000000000000004D
00C2 Offset to Central dir 0000000000000045

00CA ZIP64 END CENTRAL DIR 07064B50
     LOCATOR
00CE Central Dir Disk no   00000000
00D2 Offset to Central dir 0000000000000092
00DA Total no of Disks     00000001

00DE END CENTRAL HEADER    06054B50
00E2 Number of this disk   0000
00E4 Central Dir Disk no   0000
00E6 Entries in this disk  0001
00E8 Total Entries         0001
00EA Size of Central Dir   0000004D
00EE Offset to Central Dir 00000045
00F2 Comment Length        0000

[farblos]

Thanks for the hint on zip64 format, @pmqs, didn't pay attention to that particular fact.

Given that FreeBSD's unzip processes t/data/zip64.zip without problems (see

# Expected (more or less) result:
# Archive:  t/data/zip64.zip
#     testing: README	 OK
# No errors detected in compressed data of t/data/zip64.zip.
# Exit value 0

in the test logs) one possible approach could be to compare the A::Z-generated zip file and t/data/zip64.zip. And here the first notable difference is that A::Z uses values different from 0xFF in the EOCD for most fields, while t/data/zip64.zip comes with all fields 0xFF. But that's all guess work.

[farblos]

But then again, in http://cpantesters.org/cpan/report/d41e7072-6493-11ea-a3e8-ef2a1f24ea8f unzip -t blows up in t/18_bug_92205.t, which is not related to zip64 format at all ...

[eserte]

It seems that one has to differentiate between freebsd9 and freebsd10 here. t/18_bug_92205.t fails only with the former, see http://analysis.cpantesters.org/reports_by_field?SUBMIT_xxx=Submit&distv=Archive-Zip-1.68&field=conf%3Aarchname%2Bosvers&field=fail%3At%2F18_bug_92205.t

[farblos]

So we have so far:

• unzip of FreeBSD 11 and 12 happily process A::Z-written zip files
• unzip of FreeBSD 10 has problems with the zip64 format written by A::Z
• unzip of FreeBSD 9 has even more problems with A::Z-written zip files

However, after digging through past test logs I think that the problems of FreeBSD 9 and 10 aren't really new, only they haven't shown up as test failures until now. For example:

Archive-Zip-1.67 on 9.3-release-p13 (http://cpantesters.org/cpan/report/0185780a-000b-11ea-a6fe-b93c1f24ea8f):

`warning: unzip -t  doesn't seem to work, may skip some tests at t/common.pm line 223.`

Archive-Zip-1.67 on 10.3-release-p11 (http://cpantesters.org/cpan/report/05553862-000b-11ea-a6fe-b93c1f24ea8f):

`warning: unzip -t  doesn't seem to work, may skip some tests at t/common.pm line 223.`

So I think we now get these test failures just because the detection of whether unzip -t works or not has changed in A::Z 1.68. And I think the easiest solution would be to revert that part of my changes and again not execute unzip -t on FreeBSD 9 and 10.

[pmqs]

But then again, in http://cpantesters.org/cpan/report/d41e7072-6493-11ea-a3e8-ef2a1f24ea8f unzip -t blows up in t/18_bug_92205.t, which is not related to zip64 format at all ...

Test t/18_bug_92205.t is concerned with zero-length files. As it happens I've just found an issue with info-zip's zip implementation when it compresses a directory and you force it to use Zip64. You can think of a directory entry in a zip file as a special case of a zero length file. Not related at all to this issue but suggests that there are still edge conditions when dealing with zero-length files. Perhaps the older FreeBSD unzip has a few of its own?

I've just had a go at building the FreeBSD unzip on Linux. I found the source for unzip here https://github.com/freebsd/freebsd/blob/master/usr.bin/unzip/unzip.c. It appears to be a front-end to libarchive.

Now I need to find the FreeBSD 9 source used in unzip/ libarchive & build them.

[pmqs]

So we have so far:

• unzip of FreeBSD 11 and 12 happily process A::Z-written zip files
• unzip of FreeBSD 10 has problems with the zip64 format written by A::Z
• unzip of FreeBSD 9 has even more problems with A::Z-written zip files

However, after digging through past test logs I think that the problems of FreeBSD 9 and 10 aren't really new, only they haven't shown up as test failures until now. For example:

...

So I think we now get these test failures just because the detection of whether unzip -t works or not has changed in A::Z 1.68. And I think the easiest solution would be to revert that part of my changes and again not execute unzip -t on FreeBSD 9 and 10.

Yep, I imagine that will ultimately be the workaround.

[pmqs]

Got the equivalent of unzip/libarchve from FreeBSD 10 to build on my Linux dev box. I can get it to fail a lot of tests in t/02_main.t and t/21_zip64.t

I think we are wasting our time expecting the older FreeBSD unzips to tell us anything sensible with these failing tests.

@farblos agree with your suggestion to just disable these test on FreeBSD 9 & 10

[farblos]

Thanks @pmqs for following up. Will wait for more test results pouring in on CPAN testers and eventually fix or work around where it is reasonable to do so.