Re: [Bug-tar] Re: Is there any documentation for '-H pax'?

[Sergey Poznyakoff]

> Let me try to comment some bugs in the man page:

Your efforts are more than welcome.

> I am sure then GNU cpio is not able to handle file names of arbitrary size.

This list is dedicated to GNU tar implementation, not cpio, not star or
any other implementation. The GNU tar info page does, indeed,
mention GNU cpio, but this should not be the reason to discuss it here.
If you wish to address any issues regarding GNU cpio, please write to
<address@hidden>.  

> In POSIX mode the maximum is 262143 chars and I am sure that GNU cpio
> will probably list these files but is unable to extract them from the archive
> to the disk.

# tar tfv archive
-rw-r--r-- 262143/262143     8 2005-09-03 01:20:16 /tmp/a
# cpio --version
cpio (GNU cpio) 2.6.90
# cpio -i < archive 
2 blocks
# ls -l /tmp/a
-rw-r--r--    1 262143   262143          8 Sep  3 01:43 /tmp/a

> The GNU tar archive format is not derived from an early POSIX standard,

I believe more than enough has been said on the subject.

> oldgnu:
> Could you please document the differences between "gnu" & "oldgnu"?

Yes, I will.

> 
> v7:
> 
> The v7 tar archive format does not support directories.

Please, be more precise. What exactly do you mean?

> The V7 tar archives format does not support symbolic links.
> The only file types supported are plain files and hard links.

Indeed. The GNU tar behaviour with -H v7 will be fixed in this regard.

> ustar:
> seems to be OK and my "tartest" program now even passes the related 
> implementation from GNU tar-1.15.1 - congratulations!

Nothing to congratulate for. To be precise, GNU tar passes
all the tests from http://download.berlios.de/pub/star/testscripts.

> I am sure that GNU tar does not support the 'star' format.

It never pretended nor pretends to offer a full-fledged support. It
does support it in read-only mode, which you can easily prove (or disprove).
In case it fails to do so I'll happily fix it.

> The 'star' archive format is from 1985 (long before GNU tar or 
> even POSIX.1-1988 drafts have been around). It is not POSIX.1-1988
> compliant.

Right.

> This is a really bas idea for an archive format name as the POSIX.1-1988
> tar archive format is called "ustar" and the POSIX.1-2001 tar archive format
> is called "pax" - none of both is called "posix" and using "posix" is
> a source for consufuion. 

I disagree. 

> Unless the GNU tar program implements more than I did
> negotiate with Paul Eggert, a base 256 number (GNU tar 8 byte 
> fields) can hold 56 bits

8 octal digits - 1 = 2097151

> and a a base 256 number (12 byte fields)
> can hold 88 bits.

12 octal digits - 1 = 8589934591

Exactly as the table states.

> GNU tar definitely is not able to handle filenames of arbitrary size.
> GNU tar seems to be limited  to 1024 chars (I did just test this with
1.15.1).

$ awk 'END { for (i=0; i<65;i++) printf("1234567890abcdef/"); }' </dev/null|wc 
-c
1105
$ awk 'END { for (i=0; i<65;i++) printf("1234567890abcdef/"); }' 
</dev/null|mkdir -p
$ tar --version
tar (GNU tar) 1.15.2
$ tar cf archive 1234567890abcdef/
$ tar tf archive
[..output skipped..]

$ tar -H v7 -cf archive 1234567890abcdef/ 
tar: 
1234567890abcdef/1234567890abcdef/1234567890abcdef/1234567890abcdef/1234567890abcdef/1234567890abcdef/:
 file name is too long (max 99); not dumped
tar: Error exit delayed from previous errors

$ tar -H pax -cf archive 1234567890abcdef/ 
$ tar tf archive
[..output skipped..]
$ ~/star-1.4.3/tartest/OBJ/i686-linux-cc/tartest < archive
tartest 1.3 (i686-pc-linux-gnu)

Copyright (C) 2002 Jörg Schilling
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Testing for POSIX.1-1990 TAR compliance...
Archive uses POSIX.1-2001 extensions.
The correctness of the size field cannot be checked for this reason.
Found 1st EOF block at 243
Found 2nd EOF block at 244
No deviations from POSIX.1-1990 TAR standard found.

> The POSIX PATH name length is not unlimited but limited to 8589934574
> bytes in case _no_ other POSIX.1-2001 extended header field is used.

Right. When referring to 'posix' the info docs mean POSIX.1-2001 format
with extended headers.

Regards,
Sergey