Extraction("Failed to set file flags") on libalpm's file db

[callb4ck]

Extraction("Failed to set file flags") gets returned whenever I try to extract Arch an linux's libalpm file db with uncompress_archive
Tried both Ownership::Ignore and Ownership::Preserve (desired behaviour is ignore).

This only happens specifically with .tar.gzip files.

Output of the file command on one of the target files: gzip compressed data, from Unix, original size modulo 2^32.

Files are generated with pacman -Fyb /target/dir/ and are located in /target/dir/sync/.
Tried to extract /target/dir/sync/* to /target/dir/extracted/* (of course without the *, it's just to represent the individual file names).

Filesystem in use: ext4 + luks;
Package manager libarchive version: 3.6.1-1;
OS: EndeavourOS (based on Arch Linux);

Both GNU tar and bsdtar don't present this problem but GNU tar presents an error regarding an unknown keyword SCHILY.fflags (Perhaps this is problem?)

[otavio]

Is it possible for you to provide a test tarball? First, I intend to improve the error reporting for this case, then see if we can handle it.

[callb4ck]

Sure, those come directly from an arch linux repository mirror:

http://archlinux.iskon.hr/extra/os/x86_64/extra.files
http://archlinux.iskon.hr/community/os/x86_64/community.files
http://archlinux.iskon.hr/core/os/x86_64/core.files

(would've uploaded on github myself but it doesn't allow me).

If you are on an Arch system it's also possible to generate such files with the stated pacman command.

Do mind that I read somewhere that it might be a problem related to libarchive and the filesystem in use, so I'm not entirely sure that you might experience this problem. But if that were the case, bsdtar would also fail since it depends on libarchive as well, but it doesn't.

I'll also add that I've tried creating an archive myself with:

1. tar caf testarchive.tar 1 2 3 (where 1, 2 and 3 were empty dirs)
2. gzip -c testarchive.tar > testarchive.tgz

and the error persisted with testarchive.tgz

[callb4ck]

Correction: Seems like using this other repo (http://archlinux.de-labrusse.fr), this weird error doesn't happen.

The repo that distributes the erroring files is this http://archlinux.iskon.hr/extra/os/x86_64/extra.files

I'll edit my last comment to use this repo: http://archlinux.iskon.hr

[otavio]

Could you create an automated test showing the error? so I can pick the PR and look at how to fix it.

[callb4ck]

Sorry if I took so long, been busy (in the meantime I temporarily fixed my program by calling the bsdtar program)

PR: #86