eggert@grand.uucp (Paul Eggert) (05/29/87)
From: eggert@grand.uucp (Paul Eggert) I spent a day last week on cpio software installation problems, and would like to amplify a point John Gilmore made in <8014@ut-sally.UUCP>: the cpio -c format does not represent enough inode numbers. It represents only inode numbers less than 2^18 = 262144. Even our venerable Fujitsu Eagle has a filesystem with 108544 inodes; some filesystems today, and many more soon, will exceed this limit. Most implementations of cpio wrongly examine just the bottom 16 bits of the inode number, even when the -c flag is used, because in the source code a crucial variable is declared "unsigned short". Some implementations (e.g. Sun UNIX 3.2; Sun has promised a fix) due to other coding errors sometimes look only at the bottom 15 bits. Hence if you want to create a portable cpio tape today, you must not trust your destination cpio to properly restore two files whose inode numbers are equal modulo 2^15: the destination cpio might mistakenly think the second file is a hard link to the first. The problem can occur even if no two source files are hard links, or even if you are using cpio -p where no tape is involved. My best workaround for this problem would be laborious: make the tape after reconfiguring the source filesystem to have no more than 2^15 = 32768 inodes. It was enough to make me switch to tar! Even if all cpios were fixed to look properly at all 18 bits, the problem will recur with tomorrow's filesystems. Let us not perpetuate an inode number limit that is too low. Volume-Number: Volume 11, Number 37