[tahoe-dev] Does fuse supports hard links ?

Brian Warner warner-tahoe at allmydata.com
Tue Dec 2 00:12:25 UTC 2008


On Mon, 01 Dec 2008 09:08:37 +0100
"denis.bonnenfant" <denis.bonnenfant at diderot.org> 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



More information about the tahoe-dev mailing list