Small issue with TAR packing

[leonbloy]

If I create a tgz with TC (8.01, I've not tested with previous versions), when I untar with Mingw's tar program ( v1.22, the one that comes with GIT for Windows), I get an error message :

tar: A lone zero block at 4

Actually it's not clear if it's an error or a warning (it turns out that's a warning).

The problem is in the TAR (not related with the gz compression).

There are several related issues (not TC related, AFAIK) with other tar/untar combinations, and the root of the problem seems to be an ambiguity in the tar format, whether an extra 512-zero-bytes trailing block is expected or not.

https://issues.apache.org/bugzilla/show_bug.cgi?id=28776#c4

I tried with a simple example (one 1-byte file inside one directory, all with one single letter) and I got 2048 bytes with TC, and 2560 with the TAR that comes with the 7Zip app. The difference comes from 512 extra trailing zero bytes. And the later does not gives the warning.

This is not critical, but I suggest that you add the extra 512 zero bytes at the end of the TAR.

[ghisler(Author)]

Sorry, I don't understand the problem - Total Commander DOES append an empty 512 byte block to the end of a TAR file.

[leonbloy]

> Total Commander DOES append an empty 512 byte block to the end of a TAR file.

It seems that there the problem is related to an extra 512 block (that is not very clear if is needed or not).

Here I link two tars produced, from the same directory (1 byte file inside a dir a/b) by TC 8.01 and by 7-zip. The difference,as you see, is 512 bytes.

https://dl.dropboxusercontent.com/u/1608708/tc/a-7z.tar
https://dl.dropboxusercontent.com/u/1608708/tc/a-tc.tar

And here is what I get from those files, when I test them with the tar (GNU 1.22) that comes inside my GIT-for windows:

Code: Select all

$ tar vtf a-7z.tar
drwxrwxrwx 0/0               0 2014-03-06 17:42 a/
-rwxrwxrwx 0/0               1 2014-03-06 17:42 a/b

$ tar vtf a-tc.tar
drwxr-xr-x 0/0               0 2014-03-06 17:42 a/
-rw-r--r-- 0/0               1 2014-03-06 17:42 a/b
tar: A lone zero block at 4

$ ls -la a*tar
-rw-r--r--    1 hernan   Administ     2560 Mar  6 17:43 a-7z.tar
-rw-r--r--    1 hernan   Administ     2048 Mar  6 17:42 a-tc.tar

[ghisler(Author)]

But why two 512 byte zero blocks? Shouldn't one be sufficient?

[white]

But why two 512 byte zero blocks? Shouldn't one be sufficient?

It seems to be simply because of the POSIX.1 specification.

[leonbloy]

> But why two 512 byte zero blocks? Shouldn't one be sufficient?

From this tar doc:

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.

Some related stuff:


http://pear.php.net/bugs/bug.php?id=5452

https://www.cs.auckland.ac.nz/references/java/ant/2013/api/org/apache/tools/tar/TarOutputStream.html#finish()

http://grokbase.com/t/ant/dev/051an719bd/do-not-reply-bug-28776-tar-task-produces-incorrect-tar-files

[ghisler(Author)]

So it was changed sometimes in the past from one to two 512 byte blocks. This doesn't really make sense, because a single 512 byte block is used as a file header, so an empty header clearly marks the end of the archive...

[white]

So it was changed sometimes in the past from one to two 512 byte blocks. This doesn't really make sense, because a single 512 byte block is used as a file header, so an empty header clearly marks the end of the archive...

As said above, there is no technical reason for it. It's simply because POSIX.1 requires it and some other tar implementations check for it. That's all.