On Wed, Jun 24, 2009 at 06:37:55PM +0200, Roland Smith wrote:
> On Wed, Jun 24, 2009 at 05:04:22PM +0200, cpghost wrote:
> > Hi,
> > 
> > is there anybody working on a versioning file system for FreeBSD
> > right now?
> > I don't care if it is native or a layer, geom-ified, fuse-based,
> > or even if it uses subversion as its backend, as long as it
> > provides some kind of transparent versioning.
> You could try devel/git? It's not a file system, but a very efficient
> directory content tracker/version control system. One of the things I
> use it for is to keep a certain directory in sync between a desktop and
> a laptop. It works equally well with text or binary files.

Yes, that's one possibility. But just like Subversion (which I'm
using extensively here), it's not really transparent.

> Or maybe http://www.nongnu.org/libsqlfs/ will do what you want? Haven't
> tried that, though.

But does it really support versioning?

I was actually thinking of a real versioning file system, with an
extended POSIX API (yet to be defined), to access all revisions of
a file system, just like with Subversion revisions.

As an example: opendir(2) would grow an additional and optional
argument "revision" to select either HEAD or some revision of the

DIR *dirp;
dirp = opendir("/path/to/dir", 0);   /* open /path/to/file at HEAD */
dirp = opendir("/path/to/dir");      /* same as above, POSIX compat */
dirp = opendir("/path/to/dir", 323); /* open dir at revision 323 */

/* From here on, readdir() would retrieve /path/to/dir entries
   at the specified revision. */

open(2) could open a file at an earlier revision:

FILE *filep;

/* open file in HEAD */
filep = open("/path/to/file", O_RDONLY);

/* open same path, but at revision 323 */
filep = open("/path/to/file", O_RDONLY, /* 0666 */, 323);

unlink(2) would remove an entry from a directory, and bump the revision
of the directory. Accessing that path from the new revision wouldn't be
possible, but the file would still be there in an earlier revision.

Modifying a file would also create new revisions (e.g. at each
write(2), or at each close(2), that should be selectable).

Of course, there would be additional API calls to traverse the
list of revisions, to access meta data (properties?, tags?,
commit logs?, ...) etc., so that the file system remains manageable.

I didn't try them (yet), but on Linux, there are some experimental
versioning file systems like:

and there's a (unmaintained?) FUSE file system at:

all of which differ in the way POSIX API should be extended and
the semantics for versioning. But there's apparently nothing yet
in the works for FreeBSD. Perhaps some layer on top of existing
file systems, or an extension of UFS/FFS that stores versioning
meta data directly at the block level?

> Roland
> -- 
> R.F.Smith                                   http://www.xs4all.nl/~rsmith/
> [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


Cordula's Web. http://www.cordula.ws/
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to