[tahoe-dev] Help adjusting buildbot after upgrade?

[Greg Troxel]

Kyle Markley <kyle at arbyte.us> writes:

> 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.
>>
>> backup on the other hand is perhaps done by storing dump or tar
>> files in
>> tahoe.  I have not figured out what I want to do yet.
>
>
> If a backup and restore were known to be happening on the same "kind"
> of system, symlinks are easy: a symlink is merely a string as returned
> by readlink(2).  Tahoe could save such strings in directory entries
> and restore them with symlink(2).  Without '..', of course, it would
> be impossible to use symlinks for navigation within the web interface
> -- but for my application I don't care about navigation, I just want
> them backed up and restored!
>
> Across systems, symlinks are more complicated because tahoe would need
> to understand the substrings representing (at least) the current
> directory, parent directory, and the path separator.  On the Perl side
> of the universe, there's a library for portably working with filename
> strings, and the ideas there may be a good place to start: perldoc
> File::Spec

I am actually not that concerned about symlinks myself, but doesn't tar
have exactly the same set of issues, and all other distributed
filesystems?  Probably tahoe needs to have a notion of a pathname and a
bunch of other things that it has so far mostly avoided by having
primitive operations in the WAPI.   For example, typing

$ tahoe mkdir 'foo/bar'

does not cause an error promptly.  This seems like perhaps a bug, and I
don't think there is any value in making filenames available that can't
be referenced on unix.  The mkdir is still running, and it's waiting for
share placement due to pubgrid firewall issues I think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101113/e4872f80/attachment.pgp>