NEW TAR

[Harti Brandt]

On Thu, 22 Jul 2004, Andrey Chernov wrote:

AC>On Mon, Jul 19, 2004 at 09:29:54PM -0700, Tim Kientzle wrote:
AC>> but they're not gtar-compatible.  (The gtar
AC>> approach has a number of drawbacks.  The primary
AC>> one being that on many systems it requires reading
AC>> the entire file twice, once to find holes and again
AC>> to actually archive the file.  It is possible to
AC>> do both in one pass if you store the sparse file
AC>> data in a different fashion.)
AC>
AC>I can't imagine the case when 2 passes are needed. Even if you have normal 
AC>file in the archive and specify -S only when extracting (it should work as 
AC>expected), only 1 pass is needed. Just stop on first '\0' and count them 
AC>until they finished, then do lseek (real case will be a bit harder to 
AC>implement because of block boundaries).

Imagine that you must store the hole data before the non-hole file content
in the archieve. In that case you must read the input file to find the 
holes, write the hole data to the archive, rewind the input file and write 
all the non-hole data to the archive. If you do it the other way around 
(hole data at the end) you get a problem when extracting. The way I see 
would be to put the hole data in-line. This is also not without problems. 
AFAIK the tar format basically requires that you know how long something 
is before you can write it.

harti