Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpfcso!hpfcdc!rsh
From: rsh@hpfcdc.HP.COM (Scott Holbrook)
Newsgroups: comp.sys.hp
Subject: Re: Do NOT use ftio or cpio for backups
Message-ID: <5570659@hpfcdc.HP.COM>
Date: 10 Jun 91 23:17:46 GMT
References: <WAYNE.91Jun7172758@dsndata.uucp>
Organization: HP Fort Collins, Co.
Lines: 43

> problem #2:
> 
>   the second problem is much more serious and it effects both cpio
>   and ftio. the problem is that the inode numbers that are written
>   to tape are limited to 64k.  under the old ATT file system, you
>   could not have more than 64k inodes on the disk.  using the
>   berkeley fast file system (like hp and sun have used for years) you
>   can have more than 64k inodes.  this means that if you have a file
>   at inode 65556 (64k+20), cpio cant tell the difference between
>   that file and the file at inode 20.  since the size if the inode
>   field is defined to be this way for compatibility reasons, i will
>   probably not see any change in cpio.

This problem has been fixed in cpio (6.5 and later releases on the
s300, 7.0 and later releases on the s800).  The problem is handled in
a way that does not change the format, but still preserves all link
information.

>   so, if you have a file with inode 65556 (64k+20) that is linked to
>   another file, when you try to restore that file, it will actually
>   link it to the file at inode 20.  this means that when you try to
>   restore your system, you could end up with, say, an article out
>   talk.bizarre linked to /dev/kmem.  in fact, when we restored our
>   disk, we had things that were just as bad, if not worse than this.

This is incorrect.  Ftio still does (and cpio did before the 6.5
release) detect inode numbers that are > 65535 and maps them to 65535.
Upon restore, both cpio and ftio detect a file with inode 65535 and
restore the file as a plain file, losing the link information.  It
does not, however link the file to the "wrong" file.  The only bad
behavior is that you end up with multiple copies of your data.  While
this isn't great, at least you aren't losing your data.

I don't know why ftio hasn't been fixed, but cpio does work properly
and will not lose any information.  I will submit a defect report
against ftio so that it can get fixed for a futrue release.

Scott Holbrook
HP-UX kernel

The opinions expressed here are mine and mine only, they do not
represent an official or un-official statement of the Hewlett-Packard
Company.