Bug 240982 - archivers/zoo can’t delete files from an archive under amd64
Summary: archivers/zoo can’t delete files from an archive under amd64
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-01 20:38 UTC by stegozor
Modified: 2019-10-01 20:39 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stegozor 2019-10-01 20:38:13 UTC
When trying to delete a file from an archive under amd64, zoo fails with the following error message:
Zoo: FATAL:  Archive header failed consistency check.

Adding a file to an archive works, and updating a file in the archive /seems/ to work but gives the same header failed consistency check error message.

An example:

$ zoo -add archive.zoo sample_text
Zoo:  sample_text --  (62%) added
$ zoo -add archive.zoo sample_text2
Zoo:  sample_text2 --  (49%) added
$
$ # After modifying sample_text2 a bit with nano
$
$ zoo -update archive zoo sample_text2
Zoo: sample_text2 --  (49%) replaced
----
Packing...Zoo:  WARNING: Archive header failed consistency check.
$
$ zoo -delete archive.zoo sample_text2
Zoo: FATAL: Archive header failed consistency check.
$
$ ls 
Desktop archive.bak sample_text
Downloads archive.zoo sample_text2

This is with zoo-2.10.1_3 and uname -a returns the following:
FreeBSD localhost 12.1-BETA1 FreeBSD 12.1 BETA1 r352546 GENERIC amd64

Please note that none of these problems occur with 
FreeBSD localhost 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 i386
(and for fun, I tested with zoo in FreeDOS 1.2 too, and the 16bit version works fine as well) so it’s probably an architecture related issue.

Finally, this might somewhat be related to bug #162804 as it was closed as FIXED but only 2 out of 4 provided patches were applied and the two others were forgotten. See bug #162804 comment #4.