>Statement 1: >If two files have identical st_dev and st_ino, they MUST be hardlinks of >each other/the same file. > >Statement 2: >If two "files" are a hardlink of each other, they MUST be detectable >(for example by having the same st_dev/st_ino) > >I personally consider statement 1 a mandatory requirement in terms of >quality of implementation if not Posix compliance. > >Statement 2 for me is "nice but optional" Statement 1 without Statement 2 provides one of those facilities where the computer tells you something is "maybe" or "almost certainly" true. While it's useful in plenty of practical cases, in my experience, it leaves computer engineers uncomfortable. Recently, there was a discussion on this list of a proposed case in which stat() results are "maybe correct, but maybe garbage" that covered some of that philosophy. >it's an optimization for a program like tar to not have to >back a file up twice, I think it's a stronger need than just to make a tarball smaller. When you restore the tarball in which 'foo' and 'bar' are different files, you get a fundamentally different tree of files than the one you started with in which 'foo' and 'bar' were two different names for the same file. If, in the restored tree, you write to 'foo', you won't see the result in 'bar'. If you remove read permission from 'foo', the world can still see the information in 'bar'. Plus, in some cases optimization is a matter of life or death -- the extra resources (storage space, cache space, access time, etc) for the duplicated files might be enough to move you from practical to impractical. People tend to demand that restore programs faithfully restore what was backed up. (I've even seen requirements that the inode numbers upon restore be the same). Given the difficulty of dealing with multi-linked files, not to mention various nonstandard file attributes fancy filesystem types have, I suppose they probably don't have really high expectations of that nowadays, but it's still a worthy goal not to turn one file into two. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
