This would almost certainly require extra permission bits to decide
> 2) For that matter, should new versions be created at open() or at
> the first write()?
> Doing it at write() allows not creating a new version if no changes have
> actually happened - but this has its own issues.
No, I think it should be done at open().
> 3) Version a 500 megabyte file. Change one block. Do it a few more
> times. Are you better off copying the whole file (which bloats your
> disk usage and kills your I/O bandwidth), or keeping deltas (the
> list of allocated blocks could be almost identical except for the
> replaced/rewritten blocks). However, this DOES make doing an fsck()
> a *lot* more interesting - is a block allocated to multiple files in
> error or not?
I'd say copy the whole file, it's not going to be any worse than
somebody manually doing cp current_version old_version; vi
current_version, although as it makes the process more automatic, it
might be happening more frequently.
> 4) What happens if you rename() a file? Can you open() a previous
> version for writing? If so, does it get versioned? How does a
> backup program restore a previous version?
There need to be extra permission bits for this, but you could have
old versions default to read-only, and possibly have a flag for,
"modified from the real version foo", or even store an MD5 sum of each
version, that way if the original was replaced, it could be detected
and clear that flag.
> 5) Let's say we use VMS-style filenames to version. foo, foo;2,
> foo;3, etc.
> Now, is open("foo;2",...) a reference to the previous version of foo
> or to a new file that happens to be called foo;2? What happens if
> some other file happens to be called foo;2 and you create a version
> of foo?
> 6) OK, since anything besides \0 and / is legal in a filename, we
> can't use ;N to version. Let's steal another field in the inode to
> do the counting. Now how does userspace reference a previous
> version easily? Can you get into a situation where different
> versions of a file have different owners/permissions?
A versioned file becomes openable as a directory as well, so that you
can see the old versions. I'm sure something like this has already
been done, I'll have to try to search it out.
> 7) Userspace support. Anybody want to open that can and take up
> worm farming? ;)
> 8) User support issues. See (7). ;)
Might not be such a big problem if we use the directory idea.
> That's just the first 10 minutes or so of thinking about things that
> could be problems that a student project won't address.
> Yes, VMS had to worry about a lot of these issues too - but VMS had
> the advantage that versioning was designed into the environment from
> very early on, and wasn't a retrofit as it would be for Linux. So
> they could make arbitrary rules like "If there's a ;nnn on the end
> of a filename, it's a version" without having to worry about
> breaking anything.
I thought ISO9660 had versioning? How do we handle that, (if at all)?
I totally agree that it would be a retrofit in to Linux, but how many
modern OSes support versioning?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/