>> [I]f you modify a file, you then have the RO copy in the lower layer
>> and the new copy in the upper layer.  If you then rm it, the
>> upper-layer copy is blown away and a whiteout created.  Then when
>> you unwhiteout() it, the lower-layer file reappears.  I would expect
>> undelete() to resurrect the upper-layer copy - ie, what was there
>> before the unlink().

> One more problem: having to use two steps to make the lower layer
> file reappear seems counterintuitive.  I'd expect unlink() to just
> remove the upper layer file so that the lower layer file instantly
> reappears.  This is clean and simple.  Why not use whiteout() if you
> want whiteout?  There'd even be a symmetry between whiteout() and
> unwhiteout().

Largely because the pathname space provided by the union mount is
expected to behave like a normal UNIX filesystem.  And in a normal UNIX
filesystem, when you unlink() something, either it fails and nothing
happens, or it succeeds, and the thing is gone.  Calling unlink() and
having it magically change the contents of the file is _weird_.

This is largely what was wrong with the old union fs: it broke these
"normal filesystem semantics" in some ways.  A union fs that uses
whiteouts cures most of these problems.

> I really really wish that unlink, rmdir, rename do not automagically
> create whiteout.  What happens if you have *no* write access in the
> upper layer but *do have* write access on the lower layer?

Then you're doing something even weirder.  By definition, the union fs
makes all its changes in the topmost layer; that's why it's called the
topmost layer - things that happen there override everything beneath.
When the mount is done, all lower layers cannot be changed (at least
not via the union mount point).

> (Assuming you can have more layers), what happens if you have write
> access on one of the intermediate layers?

Same as for any non-frontmost layer: it's effectively read-only.

> How does one remove a file from a lower layer?

One either unmounts the union fs or accesses the lower layer via some
other means.

> More problems: what happens when you remove a file, then create
> another file of the same name in the same directory and now want to
> ``unremove'' the old file?

(You're going off on another tangent here: this is shifting from
talking about the union fs to talking about generalized undeletion of
files.)  Depending on how removed files are kept around, you may be out
of luck, or you may not.

>> if i was changing UFS to implement this stuff i imagine i'd go for
>> approach #2.  any file remove converts the file to "removed" status.
>> some cleaner process would need to garbage collect whenever free
>> disk space gets low.
> I'd just leave the file in the same dir. and add a normally illegal
> char in its name.

There are only two "normally illegal" characters: NUL and slash.  Which
would you pick and how would you use it?  Realize that NUL is already
used to terminate names.

>>         int rc = flink(int fd, const char *pathname)
>> which takes a file descriptor and links it to the given pathname.
> This is useful but will open up a security hole.
[>> is now me -dM]
>> I've wished for flink multiple times already.  (Another call that
>> would be nice is an open-by-inumber call, but [...] :-)
> This too is a security hole in that it defeats the purpose of
> controlled access through path names.

I would be entirely satisfied if it's root-only.  The purposes for
which I've wanted it have been maintenance purposes for which I would
normally be running as root anyway.

The proposed flink() would likely be root-only too; the user-level
un-remove program would then be setuid root.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu