Antonio Teixeira <[email protected]> writes:
> I believe I've found a possible regression in tar (built from current
> master branch) when extracting certain archives containing hard links
> generated by rpm2archive.
>
> Steps to reproduce:
> First, download an RPM package containing hard links. I've used the
> following RPM from openSUSE Tumbleweed as an example:
> https://download.opensuse.org/tumbleweed/repo/oss/x86_64/389-ds-3.1.4+e2562f589-2.1.x86_64.rpm
>
> Then:
> $ rpm2archive 389-ds-3.1.4+e2562f589-2.1.x86_64.rpm > 389-ds.tar.gz
> $ tar -xvf 389-ds.tar.gz
>
> Which results in:
> ./etc/dirsrv/
> ./etc/dirsrv/config/
> (...)
> ./usr/share/dirsrv/data/10rfc2307compat.ldif
> ./usr/share/dirsrv/schema/10rfc2307compat.ldif
> ../src/tar: Unexpected EOF in archive
> ../src/tar: Error is not recoverable: exiting now
>
> As far as I can tell this was caused by commit
> b8d8a61b25588caca4efaf9bdd2e3f1a49da77e3
> More specifically, reverting the following changes from the commit
> seems to fix the problem:
>
> diff --git a/src/list.c b/src/list.c
> index d541cf26..8e9caf5c 100644
> --- a/src/list.c
> +++ b/src/list.c
> @@ -423,20 +423,15 @@ read_header (union block **return_block, struct
> tar_stat_info *info,
> if ((status = tar_checksum (header, false)) != HEADER_SUCCESS)
> break;
>
> - /* Good block. Decode file size and return. */
> -
> - if (header->header.typeflag == LNKTYPE)
> - info->stat.st_size = 0; /* links 0 size on tape */
> - else
> + info->stat.st_size = OFF_FROM_HEADER (header->header.size);
> + if (info->stat.st_size < 0)
> {
> - info->stat.st_size = OFF_FROM_HEADER (header->header.size);
> - if (info->stat.st_size < 0)
> - {
> - status = HEADER_FAILURE;
> - break;
> - }
> + status = HEADER_FAILURE;
> + break;
> }
>
> Note that I've only been able to reproduce this using RPM packages and
> rpm2archive. It doesn't seem to happen when creating archives with
> hard links using other tools like GNU tar or bsdtar, so I'm not
> completely sure this isn't actually a bug in rpm2archive that the
> recent changes in tar might have exposed. However, bsdtar extracts the
> same archive without errors.
FWIW, I am not able to reproduce on Fedora 44 after building 'tar' from
commit 145a671e8ad0f2443e253ea4cc95b676ed7a2847:
$ rpm2archive 389-ds-3.1.4+e2562f589-2.1.x86_64.rpm > 389-ds.tar.gz
$ tar -xvf 389-ds.tar.gz
[...]
./var/lib/dirsrv/
./var/log/dirsrv/
./usr/share/dirsrv/data/10rfc2307compat.ldif
./usr/share/dirsrv/schema/10rfc2307compat.ldif
$ rpm -qf /bin/rpm2archive
rpm-6.0.1-2.fc44.x86_64
Hopefully that information is at least slightly helpful.
Collin
