#743 closed enhancement (wontfix)

make fuse support writing

Reported by: zooko Owned by:
Priority: major Milestone: undecided
Component: code-frontend Version: 1.4.1
Keywords: fuse sftp Cc:
Launchpad Bug:


A lot of people want to be able to write to their Tahoe filesystem through FUSE. We currently have three FUSE interfaces which (if I understand correctly) are all read-only.

Change History (4)

comment:1 Changed at 2009-06-21T20:02:52Z by zooko

See also #36 (FUSE integration), which I guess is a superset of this ticket.

comment:2 follow-up: Changed at 2010-02-10T22:42:45Z by davidsarah

  • Keywords sftp added
  • Milestone changed from undecided to 1.7.0

Note that sshfs does support writing, and 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 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 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 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 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).

comment:3 in reply to: ↑ 2 Changed at 2010-06-13T03:06:25Z by davidsarah

  • Milestone changed from 1.7.0 to undecided

The improvements to SFTP mentioned in comment:2 were made as part of the work on #1037. SFTP now has full read/write support which works via sshfs.

Leaving this ticket open for the direct FUSE implementations.

comment:4 Changed at 2019-07-25T18:18:05Z by exarkun

  • Resolution set to wontfix
  • Status changed from new to closed

The other FUSE implementations have been removed (#1409).

Last edited at 2019-07-25T18:19:01Z by exarkun (previous) (diff)
Note: See TracTickets for help on using tickets.