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.
