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
People
Owner: Nobody in particular
Requestors: framstag [...] rus.uni-stuttgart.de
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Tue Jan 11 09:51:40 2011 framstag [...] rus.uni-stuttgart.de - Ticket created
Subject: disabling in-memory?
Date: Tue, 11 Jan 2011 15:51:28 +0100
To: bug-archive-tar [...] rt.cpan.org
From: Ulli Horlacher <framstag [...] rus.uni-stuttgart.de>
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 http://fex.rus.uni-stuttgart.de/ 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: horlacher@rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-685-65868 Allmandring 30 Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/
  Mon Jan 19 14:16:11 2015 michael [...] rain.bz - Correspondence added
From: michael [...] rain.bz
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.
  Mon Jan 19 14:16:11 2015 The RT System itself - Status changed from 'new' to 'open'