Skip Menu |
 

This queue is for tickets about the Archive-Tar CPAN distribution.

Report information
The Basics
Id: 25018
Status: stalled
Priority: 0/
Queue: Archive-Tar

People
Owner: Nobody in particular
Requestors: Dieter.Woerz [...] t-systems.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1032
Hi, I am using your Archive::Tar perl module. For me it seems, that your following assumption ### Apparently this should really be two blocks of 512 zeros, ### but GNU tar sometimes gets it wrong. See comment in the ### source code (tar.c) to GNU cpio. next if $chunk eq TAR_END; is no longer correct. I only found the following comment in tar.c: /* To be pedantically correct, we would check if the tarball * is smaller than 20 tar blocks, and pad it if it was smaller, * but that isn't necessary for GNU tar interoperability, and * so is considered a waste of space */ I seem to getting tar-files with two blocks of nulls at the end, followed by parts of the last file, which gnu tar and HP tar seem to ignore happily, but cause problems for Archive::Tar because it wants to read to the end of the file. Can you add a flag to new, where one can specify whether to stop reading after two blocks of nulls or to continue reading until the end of the file. Thanks in advance Dieter Wörz
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-22220-1171792467-834.25018-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 1281
Download (untitled) / with headers
text/plain 1.2k
On Sun Feb 18 04:46:12 2007, KANE wrote: Show quoted text
> Hi, > > I am using your Archive::Tar perl module. For me it seems, that your > following assumption > ### Apparently this should really be two blocks of 512 zeros, > ### but GNU tar sometimes gets it wrong. See comment in the > ### source code (tar.c) to GNU cpio. > next if $chunk eq TAR_END; > is no longer correct. I only found the following comment in tar.c: > /* To be pedantically correct, we would check if the tarball > * is smaller than 20 tar blocks, and pad it if it was smaller, > * but that isn't necessary for GNU tar interoperability, and > * so is considered a waste of space */ > > I seem to getting tar-files with two blocks of nulls at the end, > followed by parts of the last > file, which gnu tar and HP tar seem to ignore happily, but cause > problems for Archive::Tar > because it wants to read to the end of the file.
Well, later on in the 'read' loop, there's the following bit of code that is guarding against this specific situation: ### Guard against tarfiles with garbage at the end last LOOP if $entry->name eq ''; Can you tell me what problems this exactly is causing? perhaps you can give me a sample tar archive that demonstrates the problem?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.