[tahoe-dev] [tahoe-lafs] #743: make fuse support writing
tahoe-lafs
trac at allmydata.org
Wed Feb 10 14:42:45 PST 2010
#743: make fuse support writing
---------------------------+------------------------------------------------
Reporter: zooko | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: 1.7.0
Component: code-frontend | Version: 1.4.1
Keywords: fuse sftp | Launchpad_bug:
---------------------------+------------------------------------------------
Changes (by davidsarah):
* keywords: fuse => fuse sftp
* milestone: undecided => 1.7.0
Comment:
Note that sshfs does support writing, and
[source:src/allmydata/frontends/sftpd.py the SFTP frontend] has partial
write support. So we effectively have four FUSE interfaces :-)
I say "partial write support" because it looks as though sftpd.py
[source:src/allmydata/frontends/sftpd.py?rev=4119#L162 will only support
opening a file for writing] when the flags include both {{{O_CREAT}}} and
{{{O_TRUNC}}} (actually the SFTP equivalents, {{{FXF_CREAT | FXF_TRUNC}}},
but looking at line 2168
[http://fuse.cvs.sourceforge.net/viewvc/fuse/sshfs/sshfs.c?view=markup
here], sshfs does a one-to-one mapping of the POSIX flags to the SFTP
ones). It also does not support opening a file read/write (POSIX
{{{O_RDWR}}}).
The first restriction could fairly easily be relaxed: if the file does not
already exist, then it's unnecessary to require {{{O_CREAT | O_TRUNC}}},
because just uploading the whole file as the current code does will do the
right thing.
If the file does already exist, or to support {{{O_RDWR}}}, then we need
to download the current contents, and also probably extend the
[source:src/allmydata/frontends/sftpd.py?rev=4119#L38 WriteFile class] to
implement a more complete read/write abstraction with a seekable file
pointer. That's more work, but I don't see any fundamental obstacles.
Note that
[http://www.opengroup.org/onlinepubs/9699919799/functions/fopen.html POSIX
specifies that] a call to the stdio {{{fopen}}} function with mode
{{{"wb"}}} or {{{"w"}}} will open the file as if by a call to {{{open}}}
with flags {{{O_WRONLY | O_CREAT | O_TRUNC}}}. So this is quite a common
combination of flags for real-world programs to use.
So, should we concentrate on getting write access to work via sshfs and
SFTP, or via the blackmatch FUSE implementation? We could do both, but I
think that would involve redundant effort, and that the SFTP approach is
probably more useful. I don't immediately see any way in which our own
FUSE plugin could provide a more successful mapping than via sshfs and
SFTP (given that the SFTP protocol is designed to correspond fairly
directly to POSIX filesystem APIs).
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/743#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list