🚀 go-pugleaf

From: uunet!Sun.COM!guy (Guy Harris)

> 1.  At no time has a proposal been made to standardise the binary
>     cpio format.  Only the `cpio -c' format is under consideration.

A proposal was made by Lorraine Kevra of AT&T to standardize both the binary
and character "cpio" format.  Fortunately, this proposal appears to have been
dropped in favor of a character-format-only proposal.

> 2.  The `cpio -c' format is widely in use in Europe for both Data
>     Interchange and Archival purposes.  It's widespread use can
>     be attributed, in part, to its endorsement by the X/OPEN Group.

Both the "tar" and "cpio -c" format are in wide use throughout the world.  The
major commonly available UNIX source distributions all include implementations
of "tar", but not all of them include implementations of "cpio".

> 8.  Inode numbers are not recorded.  Symbolic values (derived from a 
>     file's inode and device numbers) are stored in the header
>     block.  These values are used solely for hard link resolution.

> 9.  File types are stored in symbolic form.  Symbols are derived from
>     historical UNIX file type values.  There is room for 64
>     file types; currently only 5 are supported.

The proposal does not match what is stated in the X/OPEN Portability Guide
(January 1987).  In Volume 2, section "File Formats", under CPIO(4), it states:

	When the "-c" option of "cpio(1)" is used, the header information is
	described by:

	printf or scanf(<big string>, <list of arguments>);

	...The meanings of the items "h_dev" through "h_mtime" are explained in
	"stat(2)".

The items in question include "h_dev", "h_ino", and "h_mode".

Under "stat(2)", those fields are given their customary UNIX meanings.

I presume X/OPEN plans to alter CPIO(4) to reflect the fact that "h_dev",
"h_ino", and "h_mode" are no longer directly connected to the "st_dev",
"st_ino", and "st_mode" fields of the "stat" structure.

> 	- format cannot be extended to meet future requirements
> 		Wrong!  Implementations already exist which can
> 		archive symbolic links and contiguous files.
> 		There is far more scope for future extension
> 		than available in the proposed USTAR format.

Could you please indicate how this is the case?

Volume-Number: Volume 12, Number 11