Your message dated Thu, 24 Apr 2025 11:35:09 +0200
with message-id <d935733a-ee55-4cfd-941b-0a0f4bb78...@debian.org>
and subject line zip: Sets 'version needed to extract' to 1.0 even if there are
deflated files
has caused the Debian Bug report #606920,
regarding zip: Sets 'version needed to extract' to 1.0 even if there are
deflated files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
606920: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606920
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: file
Version: 5.04-5
Severity: minor
If the first file is "stored" file gets the required zip version wrong.
jasen@gonzo:~$ mkdir x x/a ; cd x
jasen@gonzo:~/x$ dd count=1 </dev/urandom | od > a/b
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000225439 s, 2.3 MB/s
jasen@gonzo:~/x$ zip -r foo a
adding: a/ (stored 0%)
adding: a/b (deflated 55%)
jasen@gonzo:~/x$ file foo.zip
foo.zip: Zip archive data, at least v1.0 to extract
deflate compression needs atleast version 2.0 to extract
I think file is currently trying to determine required zip version
from the header of the first file record. this often yeilds misleading
information.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (700, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages file depends on:
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libmagic1 5.04-5 File type determination library us
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
file recommends no packages.
file suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hello.
I finally forwarded this issue to the authors a few days ago.
I'm transcribing the reply from Paul Marquess (from Info-ZIP) below.
Thanks.
-----------------------------------------------------------------------
There is no issue here to fix.
Consider the structure of a zip file. Below is from the zip APPNOTE.TXT
[local file header 1]
[encryption header 1]
[file data 1]
[data descriptor 1]
.
.
.
[local file header n]
[encryption header n]
[file data n]
[data descriptor n]
[archive decryption header]
[archive extra data record]
[central directory header 1]
.
.
.
[central directory header n]
[zip64 end of central directory record]
[zip64 end of central directory locator]
[end of central directory record]
4.3.7 Local file header:
local file header signature 4 bytes (0x04034b50)
version needed to extract 2 bytes
general purpose bit flag 2 bytes
compression method 2 bytes
last mod file time 2 bytes
last mod file date 2 bytes
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
file name length 2 bytes
extra field length 2 bytes
file name (variable size)
extra field (variable size)
The start of a standard zip file consists of a 4-byte local file header
signature (value 0x04034b50) that identifies the start of a local file header.
The metadata in that first local header (including the version needed to
extract field) contains information about that local file only and NOT the
overall zip file. By design the local file header signature is used by flag the
version of the zip spec is needed to extract an individual entry in a zip
archive..
When you run the file command against a zip archive, it always uses the version
needed to extract field from the first local file header in the zip archive.
That is just a limitation of how the file command works. To get what is
requested in the original issue, file would need to scan the complete zip file
and find the maximum value for version needed to extract .
And to double check 7z does the same thing
$ touch /tmp/a
$ dd count=1 </dev/urandom | od > /tmp/b
1+0 records in
1+0 records out
512 bytes copied, 5.92e-05 s, 8.6 MB/s
$ 7z a /tmp/7.zip /tmp/a /tmp/b
7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
64-bit locale=C.UTF-8 Threads:8 OPEN_MAX:1024
Scanning the drive:
2 files, 2056 bytes (3 KiB)
Creating archive: /tmp/7.zip
Add new data to archive: 2 files, 2056 bytes (3 KiB)
Files read from disk: 2
Archive size: 1157 bytes (2 KiB)
Everything is Ok
$ file /tmp/7.zip
/tmp/7.zip: Zip archive data, at least v1.0 to extract, compression method=store
$ zipdetails -v /tmp/7.zip
0000 0004 50 4B 03 04 LOCAL HEADER #1 04034B50
0004 0001 0A Extract Zip Spec 0A '1.0'
0005 0001 00 Extract OS 00 'MS-DOS'
0006 0002 00 00 General Purpose Flag 0000
0008 0002 00 00 Compression Method 0000 'Stored'
000A 0004 0D B1 97 5A Last Mod Time 5A97B10D 'Wed Apr 23 23:08:26 2025'
000E 0004 00 00 00 00 CRC 00000000
0012 0004 00 00 00 00 Compressed Length 00000000
0016 0004 00 00 00 00 Uncompressed Length 00000000
001A 0002 01 00 Filename Length 0001
001C 0002 00 00 Extra Length 0000
001E 0001 61 Filename 'a'
001F 0004 50 4B 03 04 LOCAL HEADER #2 04034B50
0023 0001 14 Extract Zip Spec 14 '2.0'
0024 0001 00 Extract OS 00 'MS-DOS'
0025 0002 00 00 General Purpose Flag 0000
[Bits 1-2] 0 'Normal Compression'
0027 0002 08 00 Compression Method 0008 'Deflated'
0029 0004 10 B1 97 5A Last Mod Time 5A97B110 'Wed Apr 23 23:08:32 2025'
002D 0004 39 E1 57 9F CRC 9F57E139
0031 0004 80 03 00 00 Compressed Length 00000380
0035 0004 08 08 00 00 Uncompressed Length 00000808
0039 0002 01 00 Filename Length 0001
003B 0002 00 00 Extra Length 0000
003D 0001 62 Filename 'b'
--- End Message ---
