Version: 5.21q-15

Summary of Bug

The arc archiver utility, when automatically selecting the best compression
method, can write an incorrect (overstated) file size for the archived
member in the resulting .arc file. This occurs even when the chosen method
is 'store' (no compression) because a larger, unsuccessful compression
length is incorrectly used.

Details

The arc command-line utility supports multiple compression methods
(squeeze, crunch, pack, store) and is designed to pick the method that
yields the smallest size. If no compression is beneficial, it should
default to 'store'.

The bug is located within the logic of compression method selection,
specifically in the arcpack.c file. The issue is that the length of an
unsuccessful or inefficient compression attempt (e.g., LZW/crunch) is
sometimes mistakenly written as the final compressed size, even if another
method (like store) was ultimately chosen because it was smaller.

Reproduction Example

Given an already compressed file, such as image.jpg (original size: 228,084
bytes):

Incorrect Behavior (Automatic Selection): arc a image.arc image.jxl

The resulting image.arc size is 294,846 bytes, which is incorrect. The
expected size should be 228,084 (original size)+29 (header)+2 (EOF)=228,115
bytes.

Scope of Impact

This bug potentially affects files added using any method where the
compression routine first attempts an inefficient compression (like crunch
or LZW) and then falls back to a better method (including store, pack, or
squeeze)—the length of the larger, failed compression attempt is
erroneously recorded.

A patch has been also atteched to the mail which intends to fix the issue.

Regards, Gabor