Don Cragun <don.cragun at sun.com> wrote:
> >I canot speak for _very_ recent Solaris versions but for a case from 2006,
> >I would expect to see results before the latest (Build89) I checked.
> >
> >Build 89 comes with a pax man page from 2004
>
> I don't know when the man page got out to OpenSolaris, but the pax
> fixes went into Nevada build 54.
>From an ISO-9000 standpoint, an undocumented feature does not exist ;-)
> >As a result of not marking the archive, archivers that carefully implement
> >add
> >on features depending on the archive format will not unpack the sparse files.
> >
> >star and AT&T pax will ignore bit 17, other archivers may include this
> >bit in the file type with unkown results.
>
> That is a bug in star and AT&T pax (as well as in Sun's current cpio
> and pax). A bug report will be filed to correct Sun's cpio and pax
> when this case is resolved.
Your material was not clear. As it now seems that bit 17 is just added,
the results are known. Bit 17 is bejond the POSIX standard and thus ignored
by a conforming implementation to avoid problems.
> >OK; how about marking the archive in the header area past the filename?
>
> As I'm sure you know, the data describing the contents of the file
> immediately follow the header in a cpio archive. The standard does not
> allow any new fields to be added to the cpio archive format.
The standard does not allow to add mode bits beyond bit 16.
I send a description on how to extend the cpio header in an earlier mail today.
> >It seems that you are too US centric and thus do not see the problem of
> >being unable to see number pairs in a possiblily extremely long data
> >stream.
>
> As you know, the cpio header is a string of 76 octal digits followed
> immediately by the pathname of the file (c_namesize bytes including a
> trailing NUL byte) followed immediately by the contents of the file
> (c_filesize bytes). This header is not easy for humans to read. This
> header is not intended to be read by humans; it is intended to be read
> by cpio and other archivers that want to extract data from cpio
> archives. The same is true of the holes data record both in the
> ustar/pax archive format extended headers and in the initial portion of
> the file data in the cpio archive format.
The cpio header is small and it is possible to parse it as a human if needed.
I was talking about the hole list that may become really huge. It seems that
you never did try to debug this.....
I did this 2 years ago when it turned out that all GNU tar implementations
published before, did create broken sparse archives for files > 2 GB. The GNU
tar
maintainers did not work on the problem before I identified the bug and I was
trying to find the background and whether I could implement a workaround. This
was an archive with aprox. a million holes.
With today GNU tar archives I had real problems to manually scan the data.
At that time, the archive did use the old GNU tar definition from the 1990
that allows to see the hole data in pairs.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
