Re: [Bug-tar] tar -tf quits before EOF?

[Joerg Schilling]

"Dustin J. Mitchell" <address@hidden> wrote:

> I'd appreciate a bit of confirmation of my understanding of tar
> behavior.  We (the Amanda team) have a user who is seeing SIGPIPE when
> verifying a dump using 'tar -tf -'.  A truss (yep, it's Solaris..)

Just in case you don't know, this is not a mailing list for tar but one for 
gtar.

If you like to make a bugreport against tar, then this: 

        https://defect.opensolaris.org/bz/

would be the right place.

> shows the tar process happily munching data at 10k per go, and
> outputting filenames:
>
> 10350:  read(0, 0x080AA000, 10240)                      = 10240
> 10350:  write(1, 0x080AE034, 114)                       = 114
> 10350:  write(1, 0x080AE034, 121)                       = 121
> ... (actual data omitted to protect the innocent)
>
> Then, without warning, and without seeing any EOF or even a short read
> on fd 0, tar up and exits cleanly:
> ...
> 10350:  write(1, 0x080AE034, 98)                        = 98
> 10350:  read(0, 0x080AA000, 10240)                      = 10240
> 10350:  write(1, 0x080AE034, 102)                       = 102
> 10350:  write(1, 0x080AE034, 14)                        = 14
> 10350:  close(0)                                        = 0
> 10350:  close(1)                                        = 0
> 10350:  close(2)                                        = 0
> 10350:  _exit(0)
>
> and, of course, the Amanda process writing to the other end of the
> pipe gets SIGPIPE.  I believe, but have not verified with the user,
> that this occurs at the end of the tarfile.  Amanda (well, the tape
> drive really) pads the tarfile out with zeroes to a multiple of the
> block size (32k).
>
> My understanding is that tar should keep running until it gets EOF on
> its input - that there's no explicit indication within a tarfile that
> would cause tar to exit normally without reading to EOF.  A bit of

You are mistaken: the tar archive format defines a logical EOF notation within
the archive that causes tar implementations to stop reading.
In case that the logical block size for reading is the same as the logical 
blocksize used for writing, any compliant tar implementation grants to read 
up to the last block, but will not neccessarily encounter a short read caused
by reading over the physical EOF.

The exact behavior in the position of the archive data stream at logical EOF 
is however implementation dependant. Star e.g. implements a FIFO since more 
than 20 years and may read up to the physical EOF if the data stream in case 
that the difference between logical and physical EOF is less than the FIFO size.

If an archive contains structural defects, trying to read such an archive may
be aborted early.

I cannot speak for recent GNU tar versions, but gtar-1.17 and before create
archives that violate the structuring conventions for TAR archives in case that 
a sparse file with more than 4 holes has been put into the archive.

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/private/ ftp://ftp.berlios.de/pub/schily