make fuse support writing #743

New Issue

zooko · 2009-06-21T19:50:50Z

zooko commented

2009-06-21 19:50:50 +00:00

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

zooko added the

labels 2009-06-21 19:50:50 +00:00

zooko added this to the undecided milestone 2009-06-21 19:50:50 +00:00

zooko commented

2009-06-21 20:02:52 +00:00

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

davidsarah commented

2010-02-10 22:42:45 +00:00

Note that sshfs does support writing, and [the SFTP frontend]source:src/allmydata/frontends/sftpd.py 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]source:src/allmydata/frontends/sftpd.py?rev=4119#L162 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]source:src/allmydata/frontends/sftpd.py?rev=4119#L38 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).

Note that sshfs does support writing, and [the SFTP frontend]source:src/allmydata/frontends/sftpd.py 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]source:src/allmydata/frontends/sftpd.py?rev=4119#L162 when the flags include both `O_CREAT` and `O_TRUNC` (actually the SFTP equivalents, `FXF_CREAT | FXF_TRUNC`, but looking at line 2168 [here](http://fuse.cvs.sourceforge.net/viewvc/fuse/sshfs/sshfs.c?view=markup), 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]source:src/allmydata/frontends/sftpd.py?rev=4119#L38 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](http://www.opengroup.org/onlinepubs/9699919799/functions/fopen.html) 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).

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-02-10 22:42:45 +00:00

davidsarah commented

2010-06-13 03:06:25 +00:00

The improvements to SFTP mentioned in comment:71777 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.

The improvements to SFTP mentioned in [comment:71777](/tahoe-lafs/trac-2024-07-25/issues/743#issuecomment-71777) 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.

tahoe-lafs modified the milestone from 1.7.0 to undecided

2010-06-13 03:06:25 +00:00

exarkun commented

2019-07-25 18:18:05 +00:00

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

exarkun added the

wontfix

label 2019-07-25 18:18:05 +00:00

exarkun closed this issue

2019-07-25 18:18:05 +00:00

Sign in to join this conversation.