Re: exact semantics of union mounts (and TRYEMULROOT)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> What precisely are the semantics of directory operations on [mount -o
> union] mounts supposed to be?

I don't consider myself in a position to answer that authoritatively.
But, of course, I have opinions on the matter. :-)

> TRYEMULROOT is similar in that ideally (when the directory in
> question exists both in the emulation root and the regular root) it
> would behave the same way.

Well, perhaps.  Given the desire (I think) TRYEMULROOT is designed to
satisfy, I suspect its tradeoffs will be rather different in some
cases.

> So I think these should behave as follows:

Whiteouts complicate this.  I can't recall whether whiteouts are -o
union or -t union, but they can occur; even if they are strictly -t
union, a plain filesystem that got a whiteout created by being part of
-t union could be remounted as part of -o union.

Also, the 5.2 mount(8) manpage says

             union       Causes the namespace at the mount point to appear as
                         the union of the mounted file system root and the
                         existing directory.  Lookups will be done in the
                         mounted file system first.  If those operations fail
                         due to a non-existent file the underlying directory
                         is then accessed.  All creates are done in the
                         mounted file system, except for the fdesc file sys-
                         tem.

It's not clear whether what you are trying to do is to turn mount -o
union into something closer to mount -t union, but, if not, it sounds
to me as though the above preempts most of your questions.

For that matter, mount_union(8) sounds as though it contains answers to
most of those questions as well.

So, I will be assuming you are trying to turn mount -o union into
something substantially more sophisiticated than either mount -o union
or mount -t union, at least the versions I have at hand.

> For lookup, we should start at the top of the union stack and try
> looking up the target name, and descend until either we find it in
> some layer or run out of layers.  This much is pretty clear.

Agreed.  Modulo whiteouts.

> For nonexclusive create, we should do the same, and if we run out of
> layers start at the top again and, knowing that the name doesn't
> exist, continue like an exclusive create.

> For an exclusive create, [...]

Possibly.  How is O_CREAT|O_EXCL supposed to interact with whiteouts?

> Once we've ascertained that the name doesn't exist, we use the
> topmost read-write layer; that is, start at the top and descend
> skipping layers that are tagged readonly.  (But: does this strictly
> mean readonly as in EROFS, or do we skip layers that are chmod -w for
> the current user?)

Personally, I think it should be EROFS.  I can see use cases for
covering a writable directory with a readonly one.  If there really is
disagreement, I guess it needs to be a mount option.

> For remove, I think the correct thing to do is to descend until we
> find the topmost layer where the target name exists, if any, and then
> operate at that layer.

What about creating whiteouts?

> And for rename, I think the correct thing is to make like remove on
> the first (from-dir) argument, then find whatever layer in the second
> (to-dir) argument is the same volume, regardless of stack order.
> This can result in moving a file under another file, but that's what
> Plan 9 does and I guess it's ok.

Maybe.  For what value of "ok"?  It seems to me that if rename("x","y")
succeeds, "y" should then refer to the file "x" used to refer to, which
that violates.

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