bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] Re: Verifying a tar File.


From: Joerg Schilling
Subject: Re: [Bug-tar] Re: Verifying a tar File.
Date: Mon, 22 Aug 2005 16:56:43 +0200
User-agent: nail 11.2 8/15/04

Sergey Poznyakoff <address@hidden> wrote:

> Joerg Schilling <address@hidden> wrote:
>
> > There is also a general non TAR compliance with sparse files inside GNU tar
> > archives.
> > 
> > I reported this missconception in 1994 (together with a decription on
> > how a backwards compatible correction could be made) but no no avail until
> > now...
>
> It has been fixed with the introduction of support for PAX format.

What GNU tar uses to support sparse files on top of POSIX.1-2001 is (from my
understanding) not POSIX compliant and has it's own pitfalls...

It is e.g. limited to ~ 120 million holes or 1 TB file size with maximum 
holeyness/
In addition, POSIX defines that multiple occurrences of the same keyword
overwrites the old value; you should better have talked to me before 
implementing this (as you did propose when you did start implementing 
POSIX.1-2001 support).

Do you remember that you did promise to avoid introducing similar but
incompatible new features in GNU tar?


> > The size of sparse files in GNU tar is the size of the compressed file plus 
> > the
> > size of the sparse hole list, but GNU tar only uses the size of the 
> > compressed file for the tar header.
>
> The size of the sparse hole list can easily be deduced using the
> available information.

Only by an application that is aware of the GNU tar design bug.

> > If GNU tar would use the right size in the archive header, then there was no
> > need to correclty detect sparse files in order to list them.
>
> There is no use to fix GNU tar format in this regard since doing so
> would break backward compatibility. Flowed or not, it is the format used
> for many years and there certainly are lots of already created archives
> whose existence should be taken into account when taking a decision
> about any "improvements" to the existing format.

There are few sites that today still use the GNU tar version that was recent
in 1994. If the GNU tar maintainers did follow my proposal to implement the
"extended flag" to be set to 2 in case that the archive follows generic TAR
size rules, but did not switch the feature on by default in create mode,
there was no such problem if you did make it the default today...


 Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden           (uni)  
       address@hidden   (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily




reply via email to

[Prev in Thread] Current Thread [Next in Thread]