#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: |
Description
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
comment:2 follow-up: ↓ 3 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
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).
See also #36 (FUSE integration), which I guess is a superset of this ticket.