Don Cragun <don.cragun at sun.com> wrote:
> >A strong reason for going to star. Star implements all available features
> >in it's "star" personality.
>
> Your star archiver uses extended headers to encode the holes data.
> There are no extended headers in cpio format archives. The customer
> insists on cpio format archives.
Are you 100% that a customer likes to get enhancements in an outdated archive
format? It sounds more reasonable to ask for the cpio(1) cmdline interface.
Do you know the reason for asking for a cpio based archive format?
In any case, the advantage of star is to have a single implementation that
support different the CLI for tar, cpio, pax, ...
> >For cpio archives (see SUSv2), the standard just mentiones that archives that
> >contain "additional file types" should not be transported to other systems.
> >Will the man page include a hint on the portability issues?
>
> You're correct. I didn't go back to the 1990 POSIX.1 standard after
> reading the rationale in the current standard. Until I went back and
> looked at it this afternoon, I thought the requirement was to extract
> an unknown file type in any archive format as a regular file and to
> print a diagnostic message saying that the conversions to regular file
> had been done. Our current cpio and pax convert files of unknown type
> to a regular file, but don't print a diagnostic. When this case is
> approved, a bug report will be filed so cpio and pax will print a
> diagnostic in this case no matter what archive format is being read.
OK
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
