Your message dated Thu, 19 Feb 2009 09:32:41 -0600
with message-id <[email protected]>
and subject line Closing this bug
has caused the Debian Bug report #494169,
regarding libarchive-dev: Please add a way to precompute (non-compressed)
archive size
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
494169: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494169
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libarchive-dev
Severity: wishlist
Hi,
I thought I already reported this, but apparently I didn't so here's the
idea: I'm the author of mod_musicindex, in which I use libarchive to
send on-the-fly tar archives to remote clients.
Right now, the remote client's browser cannot display any ETA /
%complete for the current download since I cannot tell before hand what
will be the exact size of the archive I'm sending them.
It would be very nice if there were some API allowing for the
precomputation of the final size of a non-compressed archive that would
allow me to do something like:
archive_size = archive_size_header(a);
for (<filename in file list>) {
archive_size += archive_size_addfile(filename);
/* or using stat() and eg archive_size_addstat() */
}
archive_size += archive_size_footer(a);
(brainfart pseudo code, I hope you get the idea)
so that in the end archive_size will be exactly the size of the output
archive (header/padding included), without having to actually read files
or write the archive itself.
I could thus send the remote client the actual size of the data they're
going to be send beforehand.
The trick is, this size cannot be approximate: the browser will cut the
transfer even if I'm still sending them data if it has received as many
bits as it was told.
I'm under the impression that since this is about non-compressed
archive, and considering the structure of a tar archive, my goal should
be feasible without even having to read any input file. Am I wrong?
Hope I'm quite clear, thanks for your help
T-Bone
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 2.6.22.14 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
--- End Message ---
--- Begin Message ---
Tim has provided a recipe to do this with facilities already in the
library.
--- End Message ---
