Re: undeletion at filesystem level or in extra filesystem?

[Niels Möller]

tb@becket.net (Thomas Bushnell, BSG) writes:

> At this point, it seems like the filesystem already supports
> everything we need, but we need a set of conventions about how to use
> it, so that programs like rm don't actually issue dir_unlink calls,
> but do something more clever.

I hope you mean putting it into glibc, so that the rm program won't be
special?

I can see two reasons to put the versioning features in the filesystem
rather than in glibc: (1) one might want to configure versioning per
filesystem, (2) one might want to support some filesystem with
"native" versioning (are there any?)

By the way, do you think there's any chance to change the semantics of
open and write? I'd like the default behaviour to be as follows:

When a file is opened for write, one should "almost" create a new
inode. Write should not any immediate effect on other processes that
open the file for reading, or already have it open. When the file is
closed, the new inode is copied over the old one (linking is not
enough, it must be the same inode), and the old one can be linked in
as an old version in some way or the other.

If the process exits with EXIT_SUCCESS, the file is closed normally,
just like above (except if it's using libc stdio, and runs out of
diskspace on he final flushing of stdio buffer. In this case, it might
even be a good idea to have libc change the exit code, as the program
is not "successful" in any meaningful way. But that's an orthogonal
libc problem).

If the file exits with a exitcode different from EXIT_SUCCESS, the
file should be discarded, and the old file is not changed. The same
thing if the program execs and the file have the close-on-exec flag
set. There should also be some call that explicitly closes the file
and discards the changes.

Like I said, this should be the _default_ behaviour. One should be
able to get the traditional behaviour either by some new O_* flag on
open, or by mounting the filesystem with the --posixly-correct option.
I'm not sure what should happen for opening in O_RDWR-mode, it seems
best to make a "copy-on-writish" copy of the file which is commited on
close perhaps, or do the simple thing and let it imply the traditional
behaviour.

/Niels