> Nit: there are union mounts, and there is unionfs.  They are different.

True.  Are they different in this respect?

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

Or rather, it's not willing to go to the trouble to do so.  It could in
principle maintain a mapping table, and to avoid occasional breaking of
the sorts of code already named here, it really should.

> Files either exist in the upper or the lower file system (as seen
> through unionfs), so to have unique inode numbers, the two file
> systems would have to be coordinated.

...or unionfs would have to map inumbers as they pass through it, which
is what it really ought to be doing (not that I can't understand why it
doesn't, of course).

> 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.

Now _that_ could confuse code: fstat()ting the same fd gives different
inumbers at different times!  Above, I'd suggested that perhaps unionfs
should shift all inumbers over one bit, with a 0 low bit being one
layer and a 1 low bit being the other - but that doesn't address this
problem; I don't really see any choice except a mapping table.

Ugh.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B