views:

244

answers:

5

I did some literature research about versioning file systems. Versioning was already common practice in the very early operating systems such as the influential but almost forgotten Incompatible Timesharing System (ITS) and TENEX. OpenVMS, the successor of TENEX, seems to be still used in special applications and it still supports versioning. I found a number of experimental and historic file systems with versioning (see the ext3cow FAQ). But none of the major operating system (Linux, Windows, Mac OS) support versioning by default.

How come modern operating and file systems' do not support a feature available 40 years ago? Of course you can hack versioning into your systems somehow but this should be supported to the most basic level, transparent to applications. Just to clarify: Journaling and snapshot facilities (such as Apple's TimeMachine) are not the same. Versioning on file system level means: every process that modifies a file, automatically triggers the creation of a new version that you can directly access afterwords (for instance to undo the process). You can implement this cheaply with copy-on-write.

The only modern application of a versioning file system that I found is versioning in Amazon S3 which they introduced a few month ago. Why are there so little versioning file systems? What happened to progress of computer systems? Is versioning a bad idea anyway?

+2  A: 

If I have things that require versioning, there are plenty of ways to do it (local git repository, networked version control systems, etc.). I suppose the worry has been that if you create a new version EVERY time a file is changed, sooner or later your disk is just filled with diffs that you may or may not need (temp/swap files, etc.). Snapshots like time machine are sort of a middle ground - they let you go back, but don't spend a lot of space backing up (arguably) needless "churn".

Curtis
+4  A: 

Can't give you the ultimate answer, but consider these 2 points:

  1. The feature is of little use to the mainstream user (98% of all users?), so why implementing it, if nobody uses it.
  2. Storage space was expensive in the past, so why wasting it on a feature that almost nobody will use?
MicSim
Good points, but now space is cheap. You could limit versioning to specific files and only need to store the differences anyway. I doubt that the feature is of little use to the mainstream user. Many end user programs support an "undo" function but it stops if you save the file and close the program. With versioning on the file system level you provide better.
Jakob
1 - it's MORE use to the mainstream user who wants the old version of a document and doesn't use git/svn for everything they write.2 - if you could afford it on 32Mb drives, why can't we afford it when we have a mostly empty 1Tb drive?
Martin Beckett
@Martin: 1-Agree. But how often do you need this feature, if you aren't a 'coder'? 2-Maybe companies could afford it back in that days, but not normal users in late 80s/early 90s. I remember often deleting unneeded stuff on my HD because I was running out of space.
MicSim
@MicSim - how often has a user come to you for a backup of a Word file that has corrupted, or they saved a new file over one they needed. VMS was wonderful for this. As long as the FS didn't store deltas for pagefile and hiberfil you could have years worth of undo on a modern drive.MS (with VSS) and Sun (VFS) can do this - but it's hardly available to a regular user.
Martin Beckett
@Martin: I fully agree about VFS being nice to have and also that it could be easily used our days. My above points just hold for the childhood of PCs.
MicSim
And then you do some video editing and have wasted a lot of GBs of hard disk space. Or you try to build firefox from source - a few more GB gone. Or you want to import the Stack Overflow data dump, which comes in GBs of Xml files and produces about the same amount of database files. And if every version of that database is saved separately... Point being: there are lots of ways to waste space on a modern PC.
sth
+2  A: 

Versioning tends to not be useful in the majority of cases where disk writes are involved. Lots of changes happen that are meant to be one-way, and no one ever cares what the previous version was.

Plus, its hard. Implementing a file system to handle versioning is inherently more difficult than making a file system that doesn't. There is just no real incentive to create a file system that does this. The new systems (zfs, ntfs, btrfs) can do this because there is a new state of competition based on features, so they are all attempting to cram as many features as possible into their FS designs.

Most people are happy to use a VCS on the files they actually care about, not wasting space on FS versioning.

Adam Shiemke
+1  A: 

According to Darwin, evolutionary features which are not actually used tend to become de-selected. If there were a real and widespread need for this, major operating systems would include it as a default.

I used VMS a few years before the PC made its appearance. I had dozens of copies of everything I did, like it or not. I had no idea what most of them were, and didn't care. They quickly became clutter. Apparently Versioning File systems are another of those "It Seemed Like a Good Idea At The Time" things...

mickeyf
+1  A: 

Most file system designs today are taken from Unix operating systems design (like Unix has hierarchical FS before VMS), as Unix become more popular then its FS become the main stream. Then these concepts were taken to other OSes. Unix had not versions of files.

Later, different approach was taken for keeping older version - snapshots. They have advantage in that they are atomic and take entire snapshot of all system. It has also significant advantage of saving lots of space for files that are partially updated.

So today, if somebody thinks of supporting versions it is better to do with snapshots (as many file systems are support them and of course all modern storage systems).

So, this useful feature died together with operating systems like OpenVMS (that is almost dead today)

Artyom
Yes, I like Unix and POSIX was a great success - but it also hinders progress. For example it is completely nonsense to treat file names as sequences of bytes (including nasty control characters) without known encoding instead of simply switching to Unicode. I wonder whether versioning files also died because of tradition or because it is not useful enough.
Jakob
@Jakob I worked a lot with versioned file system. It is more headache then real useful thing, especially when 99% of 3rd part tool assume that there is one such version."For example it is completely nonsense to treat file names as sequences of bytes." - I totally disagree - it makes design much easier and simpler. Also all modern Unix use UTF-8 so it is not really a problem (I mean Unicode)
Artyom
@Artyom Maybe it's a henn-and-egg question with file systems and applications that work with files. On Unicode see http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#utf8 (I even broke github with control characters in file names: http://github.com/nichtich/badnames ;-). Versioning file systems may also have died because of little benefit. But allowing arbitrary bytes in a <em>name</em> (which semantically was always build of characters that only happened to be encoded by bytes in the old days) is archaic and proves that standards can block progress.
Jakob
@Jakob is this better to work like on Windows where fopen can't open files with Unicode file name? I don't think so. There are much more broken Windows application in work with Unicode file names then Unix ones...
Artyom