Skip Menu |

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

Report information
The Basics
Id: 56047
Status: new
Priority: 0/
Queue: Archive-Tar

Owner: Nobody in particular
Requestors: kane [...]

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

CC: Chris Williams <chris [...]>, bug-Archive-Tar [...]
Subject: Re: Archive::Tar derivative Archive::Tar::StreamingPile Author Credit
Date: Mon, 29 Mar 2010 11:21:08 +0000
To: Michael Greb <michael [...]>
From: "Jos I. Boumans" <kane [...]>
Download (untitled) / with headers
text/plain 1.9k
(cc:'d the bug tracker so we have a common record of this) On 28 Mar 2010, at 23:46, Michael Greb wrote: Show quoted text
> Greetings, > > I recently had need for creating some monstrously large tar files, > containing as many as over 100k files each, some of which were > multiple gigabytes large. I liked the implementation of the > Archive::Tar dist with the exception of the memory usage, as you > might imagine. I looked at Archive::Tar::Streamed as well but it > didn't suit my purposes as I needed the name the file appeared as in > the tar archive to differ from the source file's name on disk. > > I have created Archive::Tar::StreamingPile and intend to upload it > to the CPAN. It uses some code from Archive::Tar::Constants and > Archive::Tar::File. I think there were a few lines from > Archive::Tar itself as well. I stripped out the unnecessary bits > for my use-case. IO::Gzip/IO::Bzip support, extracting archives, > etc. I would have just depended on the Archive::Tar dist but I am > targeting Perl 5.8 and this would add quite a few non-core > dependencies. > > I would like to add the two of you as authors for > Archive::Tar::StreamingPile as the code is largely yours. I just > added some glue here and there and removed pieces not necessary. > Please let me know what you think of that? > > You may browse the code at <;a=blob;f=lib/Archive/Tar/
> >. I've encluded the rendered POD below as I'm using Pod::Weaver.
This would require some tweaking to the current code base to add a constructor that wouldn't 'just' proxy to new() but is backwards compatible and some option that would make add_file() write to disk rather than loading another object into memory. Chris, you think it's possible to retrofit, or is the above approach to be preferred? -- Jos Boumans "Never ask a man what computer he uses. If it's a Mac, he'll tell you. If it's not, why embarrass him?" - Tom Clancy

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

Please report any issues with to