Date:        Tue, 16 Dec 2003 18:17:39 -0800
    From:        Bill Studenmund <wrstuden@NetBSD.org>
    Message-ID:  <20031217021739.GC27951@netbsd.org>

  | unionfs does not guarantee unique inode numbers, as it can't.

unique inode numbers, no, but that's not required, unique (dev,inode)
pairs are what is required.   unionfs is attempting to present the
illusion of being a file system, when it isn't - that is, it is attempting
to make everything have a consistent st_dev - when it need not.

The right solution for unionfs is for it to simply return the underlying
(st_dev,st_ino) for the actual inodes, in the real file systems, that are
holding the files.

This will then have the appearance of a very ugly mess of unusual mount
points - but at least the semantics would be correct.

  | More damaging to the concept of unique inode numbers is the fact that the
  | inode number of a file can change. If it is only on the lower file system,
  | then it is written, it will be moved up to the upper file system. The two
  | versions of the file can have different inode numbers, so stat(2) calls at  
  | different times will give different answers.

This isn't damaging to the concept of unique inode/dev pairs, it doesn't
affect that concept at all.   It does however make for an unusual change,
that most programs aren't expecting, and very security conscious applications
might have cause to object to.    Overall however, this one is much less
of a problem than even considering the possibility that two different
files may have the same (dev,ino) pair - unionfs really MUST be fixed to
avoid this.

kre