On 11/10/10 8:05 AM, Kyle Markley wrote: > On Wed, 10 Nov 2010 07:53:46 -0500, Greg Troxel <g...@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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
