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

[Joerg Schilling]

Sergey Poznyakoff <address@hidden> wrote:

> > Let me try to comment some bugs in the man page:
>
> Your efforts are more than welcome.

So please first read my original mail again......
You have been to fast with your reply.


> > 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>.  

If the GNU _tar_ man page claims things that are obviously incorrect,
these claims should be corrected, or do believe otherwise?


> > 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 UID is a number that is related to file ownership.
----> The file name length is something completely different (related tp e.g. 
        PATH_MAX).

please reread my original text and try to understand it.


> > The GNU tar archive format is not derived from an early POSIX standard,
>
> I believe more than enough has been said on the subject.

Does that mean that you will finally correct the GNU tar man page?

What the GNU tar man page claims is doubtlessly wrong!
If you like to keep a moderated variant of the current text, then
please change "early POSIX standard" -> "early draft of the POSIX standard"
_and_ in addition prove that there really was a POSIX draft _before_ May 1986
and that this draft was not including the PATH prefix field.

As I am sure you will not be able to show us such a draft, please
make the GNU tar man page aligned with provable facts.



> > oldgnu:
> > Could you please document the differences between "gnu" & "oldgnu"?
>
> Yes, I will.

OK.

> > v7:
> > 
> > The v7 tar archive format does not support directories.
>
> Please, be more precise. What exactly do you mean?

As did say: V7 tar does only support files and hard links to files.
File type may be '\0', '0' or '1' - nothing else.
Even the BSD tar hack to mark a directory by appending a slash
does not work. 


> > 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.

OK


> > 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.

The last time I checked before (with GNU tar-1.14.9x) it did not support
POSIX.1-1988, so this is a really new feature.


> > 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.


star -cPM -Hstar typetest/ | gtar -tvf -
gtar: Archive contains `\000b' where numeric major_t value expected

The warning above is repeated mre than a dozen times, do GNU tar does not
support the archive format called "star".


> > 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.

So you will correct the GNU tar man page and the GNU tar source to 
name it correclty "xstar"?


> > 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. 

Why?


> > 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.

???????

base 256 != base 8 and it seems that you did not prove the content of 
the table.....read my orginal mail before answering again.



> > 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..]

Besides the fact that GNU tar-1.15.2 does not seem to exist, he is the proof 
that GNU tar does not support longer filenames:

 p L.mk 
#!/bin/sh

for i in 1 2 3 4 5 6 7 8 9 0; do

mkdir -p 
0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234
cd 
0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234

./L.mk
gtar -cf- 0* > /dev/null
gtar: 
0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234/0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234/0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234/0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234/0123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.1234:
 
Cannot stat: Dateiname zu lang
gtar: Error exit delayed from previous errors
 
This is a fail at 1024 + 256

So it is obvious that GNU tar _has_ a limitation on the file name length.


> > 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.

"While the GNU tar _implementation_ is limited to a path name length of
1024, the GNU tar archive format allows a maximum pathlength of (1 << 88) -1
and the "pax" archive format allows a maximum pathlength of 8589934574."

This would be a correct text.

Note that none of the numbers equals "unlimited" which is what I see in the
GNU tar man page.



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