Latest unzip update breaks programs dependent on unzip output
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unzip (Ubuntu) |
Fix Released
|
Critical
|
Martin Pitt |
Bug Description
The latest version of unzip has a bug which moves the filename from the zip listing from last position to first. Therefore, any program that relies on parsing unzip output will fail to recognize it as a valid output. I first noticed this in mc. Example:
> unzip -v test.zip
Archive: test.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
test.txt 32 Defl:N 30 6% 02-14-06 17:57 4ebb4896
-------- ------- --- -------
32 30 6% 1 file
> unzip -l test.zip
Archive: test.zip
Length Date Time Name
-------- ---- ---- ----
test.txt 32 02-14-06 17:57
-------- -------
32 1 file
You can see that the headers are ok, but the 'name' field shows up where the 'length' should appear, instead of being last.
The bug was probably introduced by the change in the outputting function (from changelog):
* unzpriv.h, Info macro:
- Use snprintf() instead of sprintf() as inner formatting function.
- Use fputs() instead of fprintf() as outer function to ignore leftover
format strings which might not have been substituted in the inner
snprintf().
description: | updated |
description: | updated |
description: | updated |
Confirmed.
For example, ark (kde archiver tool) can't list files inside a zip archive.