[EMAIL PROTECTED] (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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
