[tahoe-dev] zsh completer

[Greg Troxel]

While I certainly agree with the notion of examining how tahoe and
traditional filesystems differ and designing interfaces to bridge the
gap, the current situation could be significantly improved by
programming effort without having to solve those lofty issues.

I'm sure most people on the list know the history, but for those new to
Unix: originally there was just one filesystem, and then it was spiffed
up to be the BSD fast file system with better properties, and then with
NFS the vnode interface was introduced to decouple logical filesystem
operations from a particular backend implementation.  Other filesystems
(LFS on BSD, ext* on Linux, coda, HFS on mac) all use the vnode
interface as the dominant mode.  My real point is that a VFS-based
interface (and specifically FUSE) should be the standard approach to
accessing tahoe to the point where there is fairly little need to access
files through the other means; I view making direct mounting fully
satisfactory as one of the top challenges.

Tahoe certainly is based on capabailities, but it also has directories
that map names to capabilities, and root aliases.  Ignoring mutable
files for a moment, it's certainly sensible conceptually to mount a
rootcap into a filesystem and have the OS treat that tree as accessible
only to the uid that provided the rootcap in the mount.  Files/dirs
accessed by RO caps should appear 0400/0500, and those accessed with RW
caps 0600/0700.  sshfs/sftp at least mostly does this (I'm not 100%
clear on the uid access rules, and suspect it varies by platform).)

In some sense capabilities are like inode numbers (except of course that
they are capabilities :-), but security properties aside they fit
conceptually very well into the unix name/inode paradigm.  NFS has large
numbers under the covers that are effectively hidden from users and the
vnode interface.

It's certainly a remaining challenge to figure out how to control the
use of mutable vs immutable files, how to extract capabilities, and how
to represent checking and health.   Arguably the vnode interface may
need a new "get cap" control operation, but if that's what it needs we
can just add it.
-------------- 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/20110126/d4bf9eeb/attachment.pgp>