[tahoe-lafs-trac-stream] [tahoe-lafs] #1353: make the FUSE interface be a supported, first-class feature
tahoe-lafs
trac at tahoe-lafs.org
Fri Feb 4 20:16:45 PST 2011
#1353: make the FUSE interface be a supported, first-class feature
-------------------------------+--------------------------------------------
Reporter: zooko | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone: undecided
Component: documentation | Version: 1.8.2
Resolution: | Keywords: fuse docs
Launchpad Bug: |
-------------------------------+--------------------------------------------
Comment (by davidsarah):
Replying to [comment:5 davidsarah]:
> Replying to [comment:2 slush]:
> > I vote for tighter integration/support for PyFilesystem. It can give
us almost instant support for FUSE and Windows virtual disk, both with
nice unit tests. I know PyFS is quite young project, but it works and we
don't need reinvent the wheel. And as a contributor of PyFS I will be more
motivated to improve Tahoe-LAFS support if it become more used ;).
>
> Hmm, I might be missing something, but I don't see support for Windows
virtual disks in the documentation. There is {{{fs.expose.fuse}}}, which
depends on FUSE, but there's no Windows equivalent of that.
Oh, I missed
[http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/expose/dokan
fs.expose.dokan] (because it is not documented at
http://packages.python.org/fs/expose.html).
OTOH, the way that the interface to dokan
[http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/expose/dokan/__init__.py#295
here] maps from POSIX-style open flags to fopen-style flags, loses
information and is definitely not going to be sufficient for many
applications. (That is, the "TODO: I'm sure this misses some important
semantics." comment in that code is absolutely correct.)
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1353#comment:6>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list