Skip Menu |

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

Report information
The Basics
Id: 64696
Status: open
Priority: 0/
Queue: Archive-Tar

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

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

From framstag [...] Tue Jan 11 09: 51:39 2011
MIME-Version: 1.0
X-Spam-Status: No, score=-8.8 tagged_above=-99.9 required=10 tests=[AWL=-1.800, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Content-Disposition: inline
X-Spam-Flag: NO
content-type: text/plain; charset="utf-8"
Message-ID: <20110111145128.GA8910 [...]>
X-Virus-Scanned: Debian amavisd-new at
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: -8.8
Received: from localhost (localhost []) by (Postfix) with ESMTP id E377E2413F9 for <cpan-bug+archive-tar [...]>; Tue, 11 Jan 2011 09:51:39 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UOE-t8TAHpEr for <cpan-bug+archive-tar [...]>; Tue, 11 Jan 2011 09:51:37 -0500 (EST)
Received: from ( []) by (Postfix) with SMTP id 4CC0B2413F8 for <bug-archive-tar [...]>; Tue, 11 Jan 2011 09:51:37 -0500 (EST)
Received: (qmail 11620 invoked by uid 103); 11 Jan 2011 14:51:36 -0000
Received: from ( by with QMQP; 11 Jan 2011 14:51:36 -0000
Received: from (HELO ( by (qpsmtpd/0.80) with ESMTP; Tue, 11 Jan 2011 06:51:33 -0800
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39D3EDBA71 for <bug-archive-tar [...]>; Tue, 11 Jan 2011 15:51:30 +0100 (CET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id P7L2l2xqthee for <bug-archive-tar [...]>; Tue, 11 Jan 2011 15:51:29 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 8F690DBA70 for <bug-archive-tar [...]>; Tue, 11 Jan 2011 15:51:29 +0100 (CET)
Received: by (Postfix, from userid 1001) id 7E8FCFF56; Tue, 11 Jan 2011 15:51:28 +0100 (CET)
Authentication-Results: (amavisd-new); dkim=pass header.i= [...]
Delivered-To: cpan-bug+archive-tar [...]
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: disabling in-memory?
Return-Path: <framstag [...]>
X-RT-Mail-Extension: archive-tar
X-Original-To: cpan-bug+archive-tar [...]
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=; h=user-agent:content-disposition :content-type:message-id:subject:from:date:received:received: received; s=dkim20100209; t=1294757489; x=1296571889; bh=iG8qhlu gEophk1Qkbi6YP2dJwPrr92e8bkkyLxJWtv4=; b=ancn61Dg8c8At0K03vnNfv+ j9ktrIGA4Z3PCqfe89hiUpoO3yY2Dz91Gl2xCFpvcQSduNJ4sJAN1bpsKjtKXbUt GpXdBYzNBvQm5Il9q0ehJgvZ7qEGg9eHh+IkoJrLMbGSaDQqk10gO8KniEJli8v/ XDL3WJua2MttXx8/uTV4=
Date: Tue, 11 Jan 2011 15:51:28 +0100
To: bug-archive-tar [...]
From: Ulli Horlacher <framstag [...]>
X-RT-Original-Encoding: us-ascii
Content-Length: 1244
Download (untitled) / with headers
text/plain 1.2k
This is not a bug-report, but a feature request. I hope this is ok, too, for this address. I have written a perl based application for personal file transfer of ANY size. See I want to extend the GUI client (schwuppdiwupp), so it can send more than one file in one go. For this Archive::Tar seemed an ideal module to me. But as far as I have understood the documentation, the tar archive is an in-memory object? This is a bad idea for my application, because the files can be VERY big... up to TB range. Bigger than the computers RAM in most cases. What I need is an option for Archive::Tar->new() to write directly to disk, without in-memory buffering the whole thing. I cannot use /bin/tar because schwuppdiwupp is a multiplatform program which also runs on Windows and Windows does not have a /bin/tar ... or do you have another, better idea? I am open for all suggestions! -- Ullrich Horlacher Server- und Arbeitsplatzsysteme Rechenzentrum E-Mail: Universitaet Stuttgart Tel: ++49-711-685-65868 Allmandring 30 Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW:
MIME-Version: 1.0
In-Reply-To: <20110111145128.GA8910 [...]>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: API
References: <20110111145128.GA8910 [...]>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-30814-1421694971-1953.0-0-0 [...]>
Message-ID: <rt-4.0.18-30814-1421694971-581.64696-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
From: michael [...]
Content-Length: 433
Download (untitled) / with headers
text/plain 433b
I also have this request. I run into memory issues when extracting a file once the source gzip is larger than ~60MB (55MB works, 65MB always fails). I've thought of ways to re-architect, but really I think the easiest tradeoff is to have extraction to disk. Despite the hit to performance at least it would actually work - and that's more important. It'd be nice if there was a flagged option for disk workspace instead of memory.

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

Please report any issues with to