jib/archive-tar-new

archive-tar-new's Issues

Archive::Tar 1.98 08_ptargrep.t test fail on Windows Strawberry Perl.

Hi,
https://github.com/jib/archive-tar-new/blob/master/t/08_ptargrep.t#L14
line has a problem on Windows cmd shell.

This works well both on Unix Shell and Windows cmd.

my $cmd = qq/$^X $ptargrep --list-only "file foo" $tarfile/;

Test data missing from distribution

The test data files t/src/long/foo.txz and t/src/short/foo.txz are missing from the Archive-Tar-2.34.tar.gz distribution, causing the tests to fail if the xz support modules are available.

Extracting FreeBSD kernel tarball creates /boot/kernel/GNUSparseFile.0/kernel

Extracting FreeBSD kernel tarball compressed with XZ renames

./boot/kernel/kernel to ./boot/kernel/GNUSparseFile.0/kernel

which means contains_file and extract_file methods no longer work with file not found error.

https://download.freebsd.org/ftp/releases/amd64/13.1-RELEASE/kernel.txz

Testing with:

use v5.32; use Archive::Tar;
say for Archive::Tar -> new('/opt/13.1/kernel.txz') -> list_files;

and tar tf '/opt/13.1/kernel.txz' we get the following difference:

422c422
< ./boot/kernel/kernel
---
> ./boot/kernel/GNUSparseFile.0/kernel

while both bsdtar and gtar (GNU tar) can list and extract

# tar --version
bsdtar 3.4.2 - libarchive 3.4.2 zlib/1.2.11 liblzma/5.2.5 bz2lib/1.0.8 

# gtar --version
tar (GNU tar) 1.34

---

I've installed the following FreeBSD packages before running A:T, of course (for XZ support):

• p5-Archive-Tar: 2.40
• p5-Compress-Raw-Bzip2: 2.101
• p5-Compress-Raw-Lzma: 2.101
• p5-Compress-Raw-Zlib: 2.101
• p5-IO-Compress: 2.101
• p5-IO-Compress-Lzma: 2.101
• p5-IO-String: 1.08_1

There's some info on sparse files, but I don't understand what is it, and what makes A:T do that while the CLI utilities list and extract properly.

https://www.gnu.org/software/tar/manual/html_section/Sparse-Formats.html
https://www.gnu.org/software/tar/manual/html_node/Sparse-Recovery.html

---

using Perl version 5.32.0

symbolic link test failures in t/90_symlink.t on Windows

This is a continuation of https://rt.cpan.org/Ticket/Display.html?id=149072
Filing here since rt.cpan.org is giving me 403 errors on posting, even after logging in.

We are currently skipping the Archive::Tar tests in the Strawberry Perl builds due to these test failures.

Symlinks do work on Windows, but not on all versions.

Path::Tiny tries to create one as part of its checks:
https://github.com/dagolden/Path-Tiny/blob/7a84e3c6952e8d27e3963c92e6087aac36534451/t/lib/TestUtils.pm#L26-L41

Incorrect documentation note for $Archive::Tar::WARN

The documentation on $Archive::Tar::WARN states that setting this variable to 0 is not threadsafe. That is not really accurate. It is threadsafe to set that variable to 0 as doing so only turns of a carp call. What is not threadsafe is to set this variable to 0, and then use the $Archive::Tar::error variable. However, it is threadsafe to set $Archive::Tar::WARN to 0 and use the $tar->error method to obtain error messages.

I know this is just quibbling on details, but if you want to catch warnings in a threadsafe manner, and don't want warnings handled by the current $SIG{__WARN__} handler, then setting this variable to 0 and using $tar->error is a threadsafe way to do so, and the documentation is misleading on this.

Add directory

Thanks for the great module!

How do I add a directory? If I try through the add_files, it gets added in as a file, not as a directory.

ping for patches in RT #118476

https://rt.cpan.org/Public/Bug/Display.html?id=118476

RT #103279 - Archive::Tar strips trailing whitespace from extracted file names

See https://rt.cpan.org/Ticket/Display.html?id=103279

Sparse files handled incorrectly

I noticed that Archive::Tar doesn't extract sparse files correctly, when the tarball is created using tar c --sparse -f file.tar sparse.dat

Steps to repro:

# Make a sparse file that looks to all readers to contain 10MB of NUL bytes
rm -f my-sparse-file
truncate -s 10M my-sparse-file

# This must return 0 or you're likely on a file system that does not support
# sparse files.
du my-sparse-file

# This should give the logical file size, 10,485,760 bytes
ls -l my-sparse-file

tar c --sparse -f tar-with-sparse.tar my-sparse-file

# This, likewise, should give the same number of bytes as ls(1)
tar tvf tar-with-sparse.tar

rm -f my-sparse-file
perl -MArchive::Tar -e 'Archive::Tar->extract_archive("tar-with-sparse.tar");'

The my-sparse-file will be created with a 0-byte size (should be 10,485,760).

Test failure on Windows; Where should bug reports be filed?

In addition to being released on CPAN, Archive-Tar is shipped with the Perl 5 core distribution. Within the core distribution -- specifically, within Porting/Maintainers.pl -- the place listed to report bugs with Archive::Tar is https://rt.cpan.org//Dist/Display.html?Queue=Archive-Tar.

Per that instruction, in July I opened this ticket, RT 149072, reporting a test failure in Archive-Tar-3.02 that was significant enough to keep us from upgrading the version of Archive-Tar shipped with core to 3.02 from 2.40. As of today, that ticket has not been responded to. It was only today that I realized that perhaps this problem should have been reported in this GH Issues queue as well.

We would like to get the latest version of Archive-Tar into Perl 5 core, but we need to get this test failure (on Windows) addressed. Can you investigate -- and also add an entry to the META_MERGE/resources table in Makefile.PL along the lines of:

bugtracker => 'https://github.com/jib/archive-tar-new/issues'

... if that is indeed the place where bug reports should be filed?

Thank you very much.
Jim Keenan