------------------- >[EMAIL PROTECTED] (Niels Möller) writes: > >> 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: > >But basically, yeah, if someone opens for O_WRONLY, writes, and >closes, it would be nice if the old contents were cleanly saved as a >"version". >
That could get really nasty when it comes to large files that are opened/closed frequently. It also seems to open the door to some security problems. It wouldn't take long for a 10MB log file to take up an entire disk with new versions. Also, what about frequently used directories and their inodes? How about files/directories when affected by various translators? What would happen with compressed files being translated as directories? What if I change one byte in a multi-gigabyte file with automatic versioning? How would versions affect quotas: could I create a malicious program that peforms open/edit/close on a small file and consume the entire disk? Automagic file versioning should probably be in the domain of applications, not the filesystem. If the filesystem were to support anything, it would be creating a list of inodes to use in each file, sort of like copy-on-write memory, instead using a copy-on-write inodes. But that gets back to the original problem of undelete. The VAX VMS I used as a student had automatic file versioning, and I found that I was constantly erasing versions to keep below my quota. That kind of versioning didn't do much for undelete; When I accidently deleted my work, I tended to delete with * rather than a specific version number. So I think that file versioning and undelete should be considered separate issues, and I agree with others in the group that undelete belongs outside the filesystem. Okay, my two cents are in. Bryan Wagstaff. [EMAIL PROTECTED] _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
