[tahoe-dev] [tahoe-lafs] #743: make fuse support writing

tahoe-lafs trac at allmydata.org
Wed Feb 10 22:42:45 UTC 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