Der Mouse writes:
% You certainly could.  It might even happen relatively often.  As
% someone else already noted, if 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().

Jan-Simon Pendry writes:

        operation       remove    create    remove     create
                        name      name      whiteout   whiteout

        unlink          yes       -         -         possibly
        rmdir           yes       -         -         possibly
        open(CREATE)    -         yes       possibly   -
        "undelete"      -         -         yes       -
        mknod(WHT)      -         -         -         yes
        rename          yes       possibly  possibly  possibly

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?  (Assuming you can have more
layers), what happens if you have write access on one of
the intermediate layers?  How does one remove a file from
a lower layer?

> suppose we have a filesystem which supports "unremove" - ie the total
> inverse to "remove".  the real problem to be solved is how to name
> the file and how to get from the name to the flat-store representation.

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?  What happens
when you create a new file of the same name and remove it?
Do you get back only one old copy back?  Ideally you want
all old versions so that you can examine them and restore
the right one.  But unlike under VMS, I don't normally want
to see all the old versions of a file.

Actually, instead of unremove I'd prefer transaction support
from the kernel (sort of like the way Tolerant Systems
implemented it).  This would solve so many problems...  (but
at some cost).

> 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.  A cleaner can periodically
remove or backup old versions.  I'd also add an `archive'
attribute that is ON by default but gets turned off for
files that you don't want to save.

>         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.

Der Mouse writes:
> I've wished for flink multiple times already.  (Another call that would
> be nice is an open-by-inumber call, but I don't want this to drift off
> into a fantasia on everything I've ever wanted in a filesystem :-)

This too is a security hole in that it defeats the purpose of
controlled access through path names.

There was some discussion of next generation filesystems on
one of the freebsd groups.  May be we should setup a
separate mailing list for FS:NG that is not biased towards
any particular Unix-like system.  Either that or
alt.fantasy.filesystems:-)

Bakul Shah