On Wed, 10 Nov 2010 07:53:46 -0500, Greg Troxel <[email protected]> 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
--
Kyle Markley
_______________________________________________
tahoe-dev mailing list
[email protected]
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
