Bryan Wagstaff <[EMAIL PROTECTED]> writes: > >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.
"cleanly saved" might well include saving only differences. > It wouldn't take long for a 10MB log file to take up an entire disk > with new versions. I should have specified opening O_WRONLY|O_CREAT|O_TRUNC; this is the normal modes for "writing a file", and is very different from appending to logs. > Also, what about frequently used directories and > their inodes? You can't open a directory O_WRONLY. > How about files/directories when affected by various > translators? What would happen with compressed files being translated > as directories? Translators are a separate issue, but the answer would fall naturally out of whether "cleanly saved" involves sharing an inode somehow or not. > What if I change one byte in a multi-gigabyte file > with automatic versioning? Then one could save only the small change. > 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? A malicious program could just write a big file. > 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. You seem to be saying "there are lots of complicated questions here". I agree, and I think we need clear correct answers before we start trying versioning or undelete. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
