[Note the reply-to.]

   > 2) rm(1) now has a `-W' option, which removes whiteouts, using the new
   > (and probably poorly named) undelete(2).

   Yes, this is rather poorly named.   Now would be a good time to fix
   it, before we have to provide backwards compatibility.   It seems to
   me that at some point we might want a real undelete system call, which
   this isn't.

I think the idea is that it's supposed to be `upward compatible'.
i.e.  undelete(2) only works in a certain case now, but the range of
cases may be enlarged in the future.

   How are whiteouts currently implemented?

They're a special type of directory entry, with a DT_WHT tag.  The
libc *dir(3) code handles actually removing the whiteout entries, and
the files they shadow, from the virtual directory that readdir()
returns.  (This is technically okay, since getdirentries(2) is an
internal interface.  It avoids putting all of this code in the kernel,
and having to do all the buffering there.)

   Does the
   unlink system call create a whiteout, or do you have to do something
   special?

unlink(2) creates a whiteout automatically, if the upper file system
supports it.  Otherwise it returns EROFS.

   In either case, actually, it seems to me that unlink could
   be made to do the right thing - if a file exists, white it out; if it
   is already a whiteout, remove the whiteout.

No; this would be bad.  `rm foo' should *not* remove a whiteout; it
should return ENOENT if there's a whiteout.  Anything else breaks the
current user-visible semantics.