> The pax problem is trickier. There is a hashing algorithm for hard links,
> that is just broken. I think it is broken always, and is just more likely
> to fail when there are a lot of inodes and links on the filesystem. The
If this is true how do you explain ext2/loopback (some failures) vs.
minix/loopback builds of tomsrtbt (no failures)? Wouldn't you
expect to see similar failure rates for similarly sized ext2 and minix
file systems?
I wanted to see what different archiving programs did with an
ext2/loopback file system. I archived /usr from tomsrtbt and then
simply added up the file sizes as reported by the list function of the
programs as a simple way of detecting hard link conversion:
Stock usr cpio archive supplied with tomsrtbt - 2281141 bytes
gnu tar - 2281115 --almost on the money, but how did 26 bytes get
dropped?
gnu cpio 2853464 - much worse than pax cpio
pax-cpio - 2295456 - these two are very similar
pax-pax - 2295847
How likely is it that gnu cpio and pax are both broken in the same
way, i.e., converting hard links to files? And why has this problem
of hardlink conversion gone undetected for so long with programs
as old and heavily used as gnu cpio?
