Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: rcodi@yabbie.oz.au (Ian Donaldson)
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-ID: <8298@ut-sally.UUCP>
Date: Thu, 18-Jun-87 02:21:11 EDT
Article-I.D.: ut-sally.8298
Posted: Thu Jun 18 02:21:11 1987
Date-Received: Mon, 22-Jun-87 02:11:31 EDT
References: <8188@ut-sally.UUCP> <8208@ut-sally.UUCP> <8249@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: rcodi@yabbie.oz.au (Ian Donaldson)
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 26
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: rcodi@yabbie.oz.au (Ian Donaldson)

In article <8249@ut-sally.UUCP>, std-unix@ut-sally.UUCP (Moderator, John Quarterman) writes:
> 
> [ We are discussing standardizing a data interchange/archive format 
> in a standard that its authors explicitly wanted to be implementable
> on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
> numbers is a problem for such implementations, especially when it
> is not necessary, as demonstrated by the tar format.  -mod ]

How much of a problem?  Surely the numerical value of these numbers are 
unimportant, but their relationship to other files in the same
archive is important.  They are just magic cookies specifying whether
file A is the same as file B.  Any computer can generate such
magic cookies.    

For so-called implimentations of "UNIX" (as opposed to UN*X)
that don't have linked file capabilities (gasp!) this is still not a problem,
as archives that they generate won't have linked files, and archives
that they read will simply ignore this information.  

Same goes for tar.

Ian D.

Volume-Number: Volume 11, Number 71