A question that has come up repeatedly where I work from our former VMS guys is... "will any Linux filesystem ever support versioning like RMS did"? When they talk about versioning they really are talking about something that I think would involve having apps that support versioning. For example in OpenVMS, if you use the text editor "EDT" and edit a text file:
The original file is MYLIST.TXT with a version of ;1
After you edit it, the original file is renamed from MYLIST.TXT;1 to MYLIST.TXT;2 and the newer file is called MYLIST.TXT;1
If you edit it again, then it the original becomes MYLIST.TXT;3, the second version is MYLIST.TXT;2 and the latest edit is MYLIST.TXT;1
This continues on for as long as you have files around and I believe it's configurable to limit how many versions back you retain. So this leads me to wonder if this is even possible on any Linux filesystem.
I'm aware that Emacs can produce versions of files with a configurable limit as well. But wouldn't it be nice if all apps could do it? Even nicer if the filesystem really handled it in a transparent way... AND if the versioning was reversed compared to VMS so that the latest is the highest number with the latest version having the ability to be referenced without needing to append the version number. VMS actually works like that regarding the latest version, you don't need to append the version number to the file name unless you want an older version. So, is there anything like this out there for Linux? Or is this likely to be a dead issue?
A journalling file system is not the same thing as a versioning file system. A journalling file system has a (short) log of recently-modified blocks, etc. so that, if someone pulls the cord or something in the middle of a file operation, it can see where it left off and gracefully recover instead of leaving you with a corrupt filesystem. This log is not used to keep old versions of files.
It allows you to take "snapshots" of your filesystem at specific points in time and then to access older files from the snapshots with a simple set of commands. The snapshot files do not "pollute" the standard file system. There's also a GUI that looks interesting:
NOTE: It's not yet 100% stable but it's claimed as usable. At least I now know better things are coming. I imagine other filesystems can't be far behind now that the methodology has been created... It's actually pretty ingenious. When you take a snapshot, only one thing happens: The 'epoch' counter in the superblock is updated. Once any of the files on the filesystem are altered after the snapshot point, new blocks are allocated to the modified portions of the file. So... your "old" and "new" files might actually share blocks if the data is still the same with only new modifications being allocated. Pretty cool.
