Bug 28776 - tar task produces incorrect tar files
tar task produces incorrect tar files
Status: RESOLVED FIXED
Product: Ant
Classification: Unclassified
Component: Core tasks
1.6.1
Other other
: P3 normal (vote)
: ---
Assigned To: Ant Notifications List
:
: 31984 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-05-05 02:27 UTC by Oliver Rossmueller
Modified: 2014-02-17 13:59 UTC (History)
1 user (show)



Attachments
TarOutputStream.java patch (626 bytes, patch)
2004-05-05 02:29 UTC, Oliver Rossmueller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Rossmueller 2004-05-05 02:27:34 UTC
When extracting tar files created with Ant's tar task, tar logs a warning like
'tar: A lone zero block at *'. While all the file contents is extracted
correctly this message causes confusion for lots of users. The reason for the
message is that tar expects TWO empty records marking the end of the archive but
Ant is writing only ONE. To fix this, method TarOutputStream.finish() should
look like

    public void finish() throws IOException {
        this.writeEOFRecord();
        this.writeEOFRecord(); // TWO empty records required
    }
Comment 1 Oliver Rossmueller 2004-05-05 02:29:12 UTC
Created attachment 11429 [details]
TarOutputStream.java patch
Comment 2 Antoine Levy-Lambert 2004-07-16 15:15:21 UTC
The patch of Oliver Rossmueller is making another 0 block.
Maybe we need more than that ?
What I am missing is a document defining the specification of tar.

I searched to find an implementation of tar in c, and here is what I found :
http://savannah.gnu.org/cgi-bin/viewcvs/tar/tar/src/create.c?rev=1.85&content-type=text/vnd.viewcvs-markup
/* Write the EOT block(s).  Zero at least two blocks, through the end
   of the record.  Old tar, as previous versions of GNU tar, writes
   garbage after two zeroed blocks.  */
void
write_eot (void)
{
  union block *pointer = find_next_block ();
  memset (pointer->buffer, 0, BLOCKSIZE);
  set_next_block_after (pointer);
  pointer = find_next_block ();
  memset (pointer->buffer, 0, available_space_after (pointer));
  set_next_block_after (pointer);
}
Comment 3 Peter Reilly 2004-11-01 09:11:33 UTC
*** Bug 31984 has been marked as a duplicate of this bug. ***
Comment 4 Peter Reilly 2005-01-10 17:13:51 UTC
I have found some doc on this.
info tar for gnu tar 1.13.25 (installed on fedora core 2) says this:
"The Standard Format"
===================
..
..
   Physically, an archive consists of a series of file entries
terminated by an end-of-archive entry, which consists of 512 zero
bytes.

Googling came up with a defintion for gnu tar 1.15.1:
"Basic Tar format"
..
..
Physically, an archive consists of a series of file entries terminated by an
end-of-archive entry, which consists of two 512 blocks of zero bytes. 

Note the difference in definition!.

I suppose we need to look in the gnu tar cvs for reasons for the
change in definition.

Comment 5 Peter Reilly 2005-01-11 19:32:25 UTC
Ok, I have found a "NEWS" entry for tar:
http://savannah.gnu.org/cgi-bin/viewcvs/tar/tar/NEWS?rev=1.83&content-type=text/vnd.viewcvs-markup
the relavent section is:
version 1.13.9 - Paul Eggert, 1999-08-18.

* `tar' now writes two zero blocks at end-of-archive instead of just one.
  POSIX.1 requires this, and some other `tar' implementations check for it.


So it looks like it is a good idea to output two zero blocks.
As a zero block is used to finish an archive, there should
be no BC problems with having two.

I have committed the change to ant cvs and ant cvs 1.6 branch, it
should be in the next release of ant.
Thanks for the patch.