Versioned File System

Some operating systems have provided these. They are based on providing an explicit history of each file. In concept, any write to a file creates a new version as the descendent of the one it was based on, and any time a file is opened the version to use may be explicitely specified. In practice this is obviously limited to prevent rendering versions useless by providing a surfeit of them. One means of limiting this is to configure a directory or a file to be exempt from version control. It is also possible to configure how long a history will be kept on each file by default, and to explicitely delete versions.

There must also be some limit which prevents versions from being created too often - but what?

VMS had a VersionedFileSystem, as did (some?) LispMachines.

Unfortunately, documentation on VFSes is difficult to find today.

Does anybody have more information about the motivations of VFSes and how they differ from the motivations of version repositories? The most obvious way in which a repository is superiour to a filesystem is that it can be shared across multiple computers. How could a VFS be useful despite this limitation, which seems quite severe by today's standards?

Fine-grained versioning is a fundamental property of objects. In contrast, network access is not. So use fine-grained versioning in every component of the operating system and then provide a component to give network access to it. If you want to provide a persistent distributed filestore then that too will be versioned by virtue of the fact that all components should be versioned.

When I used VMS's VFS, I assumed it was analogous to the Windows recycle bin, but much more powerful. Multiple revisions retained, and the prior versions being kept in the same "place" as the file. I think the only thing Windows recyle bin has over VMS is that deleted files are recoverable, not just prior revisions of existing files.

So, in effect, it was just protection against human or programming mistakes. -anon

I suppose that makes sense, but isn't there some mechanism which creates new versions implicitly? Or am I expecting too much?

I don't recall exactly, but I know that the "standard" editor created new versions automatically on each save or perhaps each close.

Obviously VFS was broken. Any sane system would have kept versions of directories too so that you could go back to a previous version of a directory before the file was deleted. They probably didn't do it because they didn't understand GarbageCollection at the time, let alone GarbageCollectionUnderVersioning.

In VMS, each version is a complete copy of a slightly changing document. The redundancy among the versions wasted a lot of disk space, and the weekly note from the SysAdmin Please purge your files. was needed because disk space was expensive then.

The RevisionControlSystem, RCS, stores the differences in a far more compact form, and can still recreate every version.

The newest concept, ArchivalStorage? with Venti provides a filestore where you cannot delete any files. See the paper at http://plan9.bell-labs.com/sys/doc/venti/venti.html -- the tables and graphs show interesting results -- the growth over time on scales of a decade isn't as bad as one would imagine. --ChrisGarrod

FileSystem