On Mon, 01 Dec 2008 09:08:37 +0100 "denis.bonnenfant" <[EMAIL PROTECTED]> wrote:
> Second point : > > I want to use backuppc as frontend for my servers backup. But it depends on > storages supporting hard links. Does tahoe's fuse implementation support it > ? It does, in fact Tahoe *only* supports hard links. As I described in a separate message yesterday, the Tahoe filesystem consists of immutable files, mutable directories, and (not-as-well-supported) mutable files. Each of these objects is referenced by a URI or "capability string", like a "read-cap" (which allows reading), or a write-cap (which, for mutable objects, allows both writing and reading). A Tahoe directory is simply a table that maps child name to a file-cap or directory-cap. This is actually fairly similar to how unix works under the hood, where files and directories are known by their "inode number". Both the Tahoe URI and the unix inode number are unique ways to refer to a specific file or directory object. In this sense, a "hard link" is really just what you get when two different directories each reference the same child. You can do this in Tahoe by using the set_uri() or set_children() APIs to add the same child to different directories. The general challenge when trying to map unix hardlinks to Tahoe's equivalent is in figuring out what the target object's URI/filecap is. Basically, you want to read the target object with the ?t=json parameter, extract the URI out of the response, then use the set_uri()/set_children() API to attach the old child somewhere else. The "tahoe ln" CLI command will do this for you. I don't know what approach backuppc uses, but hopefully this information might help you get backuppc to use Tahoe in some useful way. If you succeed (or even if you don't), please let us know! cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
