>> 2) add space in the file handle to indicate which export point a
>> file handle came from,
> Ok, and for two hard links to the same file in incompatibly exported
> subtrees, you end up either:
> - choosing which of the export points to indicate in the file handle
> OR
> - creating two distinct file handles for the same file (one for each
>   link) as I mentioned before

I don't see the latter as a problem, since the file handles will be for
"file as accessed via export 1" and "file as accessed via export 2".  I
don't see anything wrong with having distinct file handles for the same
file when the file is exported via two different exports; different
exports are conceptually different filesystems, so I have no projblem
with making them look different to clients.

The only surprise I see lurking is that writing the file via one
filehandle will cause the file as seen by the other to change, which is
not normally the case for different files.  I consider this by far the
lesser breakage, as compared to the file going mysteriously RO on the
RW mount (or, worse, the other way around).

This makes it relatively easy to stop ..ing across an export point,
because the root of the export will be recognizable as such by its
filehandle, permitting special-casing .. lookups.

> If you combined this with something that stops "lookup .." across the
> subtree boundary and also don't allow hard links across the subtree
> boundary, then you've got something.  (Exactly what you would have
> now by making them separate file systems on the server.)

Not quite, because of the "file on filesystem A mysteriously changes
when file on filesystem B is written to" property.  Making them
separate filesystems on the server prevents hardlinking the files
together like that.

/~\ 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