Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!uunet!ogicse!sequent!muncher.sequent.com!news
From: vandys@sequent.com (Andrew Valencia)
Newsgroups: comp.sys.hp
Subject: Re: Do NOT use ftio or cpio for backups
Message-ID: <1991Jun14.221749.16963@sequent.com>
Date: 14 Jun 91 22:17:49 GMT
References: <WAYNE.91Jun7172758@dsndata.uucp> <28510056@hpuamsa.neth.hp.com>
Sender: news@sequent.com (News on Muncher)
Organization: Sequent Computer Systems, Inc.
Lines: 16

franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) writes:

>  Since I do not have the algorithms and formats handy (is is "ages" ago
>that this was done) *and* I do not know if I can make this public, I
>leave this one to others to answer.

I don't remember how HP fixed it.  I seem to remember that when it
bit me I came up with the idea that when you emitted an entry
<h_ino, h_nlink>, after you had written the h_nlink guys for this
h_ino, the inode was now unused for the rest of the cpio dump.
Thus you could map one of your > 64K inumbers down into it and
reuse it that way.  Since inumbers > 64K are utterly broken for
cpio anyway, there shouldn't be much of a compatibility issue.

					Andy Valencia
					vandys@sequent.com