home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0036.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  1.5 KB
  1. From: eggert@grand.uucp (Paul Eggert)
  2.  
  3. I spent a day last week on cpio software installation problems, and would like
  4. to amplify a point John Gilmore made in <8014@ut-sally.UUCP>: the cpio -c
  5. format does not represent enough inode numbers.  It represents only inode
  6. numbers less than 2^18 = 262144.  Even our venerable Fujitsu Eagle has a
  7. filesystem with 108544 inodes; some filesystems today, and many more soon, will
  8. exceed this limit.
  9.  
  10. Most implementations of cpio wrongly examine just the bottom 16 bits of the
  11. inode number, even when the -c flag is used, because in the source code a
  12. crucial variable is declared "unsigned short".  Some implementations (e.g. Sun
  13. UNIX 3.2; Sun has promised a fix) due to other coding errors sometimes look
  14. only at the bottom 15 bits.  Hence if you want to create a portable cpio tape
  15. today, you must not trust your destination cpio to properly restore two files
  16. whose inode numbers are equal modulo 2^15: the destination cpio might
  17. mistakenly think the second file is a hard link to the first.  The problem can
  18. occur even if no two source files are hard links, or even if you are using cpio
  19. -p where no tape is involved.  My best workaround for this problem would be
  20. laborious:  make the tape after reconfiguring the source filesystem to have no
  21. more than 2^15 = 32768 inodes.  It was enough to make me switch to tar!
  22.  
  23. Even if all cpios were fixed to look properly at all 18 bits, the problem will
  24. recur with tomorrow's filesystems.  Let us not perpetuate an inode number limit
  25. that is too low.
  26.  
  27. Volume-Number: Volume 11, Number 37
  28.  
  29.