>>> it seems to be that the name undelete is ok.  would you have both a
>>> file available for undeletion, and a whiteout in existence at the
>>> same time?
(You easily could.)
>> You could have successive undelete(2) calls.  First one zaps the
>> whiteout, the second restores the file.
> I'm not really knowledgable on this, but wouldn't the removal of the
> whiteout imply the restoration of the file?

No.  There are two files in question: the file in the lower layer and
the (deleted) file in the upper layer.  Removing the whiteout makes the
lower-layer file visible again (it never really went anywhere; it was
just hidden).  Undeleting the deleted upper-layer file will once more
hide the lower-layer file, appearing to replace it with the upper-layer
file - ie, the situation that existed before the changed upper-layer
copy was unlink()ed.

> I was under the impression that removing a file from the underlying
> readonly FS was what causes the creation of the whiteout?

No.  Attempting to remove a file in the union fs, when that file does
in fact exist in a non-topmost layer, causes creation of a whiteout.
There is no union-fs operation that will remove a file from the lower
layer; if you do manage to remove a file from the underlying fs by some
other means (say, a nullfs mount that existed before the union mount
was done), what happens in full detail is beyond the scope of this
message :-), but I would expect that it would (from the point of view
of someone making accesses to the union mount point) either do nothing,
if there is some entry (even a whiteout) shadowing it, or will uncover
an entry of the same name in a deeper layer, or will make it vanish if
there is no such.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu