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

Okay, I'll buy this.

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

But I don't buy this.   The operation that you're performing with the
undelete syscall is not the same as the operation that you'd be
performing with if you were to actually restore a deleted file.

In the former case, you might create a file, foo, on the writable top
layer.   This file would mask the read-only foo on the bottom layer.
Now you call unlink on foo.   From what you've said, I presume that
unlink will create a whiteout on the writable top layer.   If you then
call undelete, foo will again be visible, but it will be the older
version of foo, not the newer.

The behaviour that one would intuitively expect to see in an undelete
operation would be that the newer version of foo that had been on the
top layer would be restored in place of the whiteout.   This is the
behaviour that I'd like to see in the future.

However, if people get sufficiently accustomed to the behaviour that
we will be getting from the current implementation, I think that
changing the semantics of the operation in a future version may prove
difficult, and we may be stuck with the old semantics and require a
new syscall to provide the desired semantics.   I'd hate to see a
repeat of the old wait{,2,3,4} fiasco...

The suggestion from a previous message that the syscall should be
called unwhiteout sounds reasonable to me, too.

			       _MelloN_
--
Ted Lemon							 mellon@vix.com
+1 415 477 5045

Fight to preserve your freedom to program: Join the League for
Programming Freedom!   For info, contact lpf@uunet.uu.net.