[tahoe-dev] Help adjusting buildbot after upgrade?

[Brian Warner]

On 11/10/10 8:05 AM, Kyle Markley wrote:
> On Wed, 10 Nov 2010 07:53:46 -0500, Greg Troxel <gdt at ir.bbn.com> wrote:
>> I think you have a good point about symlinks.  Probably you should file
>> a ticket so this doesn't get lost.  It isn't immediately obvious how
>> they should work, especially because tahoe does not have a concept of
>> "..".  I think it can't grow one, because .. is a huge change to chained
>> capabilities semantics.

Ticket #641 is about 'tahoe backup' being able to backup symlinks.

On the Tahoe side, symlinks would be stored as just data (a string with
the target of the link), with a flag to inform some eventual restore
program that it's a symlink and not a normal file. Nothing on the Tahoe
side would be able to follow such links: as you point out, that'd be a
complete violation of Tahoe's access semantics.

We don't really have a 'tahoe restore' command yet: 'tahoe cp' (from
tahoe into the local disk) is close. Maybe #641 should also ask for a
--restore-symlinks argument to 'tahoe cp' that would do the inverse of
what 'tahoe backup' does with symlinks. Also, maybe 'tahoe cp' (from
disk into tahoe) should process symlinks too. Maybe a --symlinks option
to 'tahoe cp', which defaults to true for 'tahoe backup'.

I think it'd be ok if the "symlinks" that got archived into a tahoe
filesystem behaved similarly symlinks that get archived into a tarball:
when you unpack it, you can wind up with dangling links that go to crazy
places which existed on the original but not on the new disk, but that's
just ok.

cheers,
 -Brian

#641: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/641