tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

only access mutable parts of a filesystem via one sshfs mount 

[Imported from Trac: page SftpFrontend, version 50]
davidsarah 2010-06-29 01:39:06 +00:00
parent 3f7e7c2d66
commit 958f6e631d
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
SftpFrontend.md

@ -47,6 +47,8 @@ sshfs is an SFTP client that allows filesystem access via FUSE (a user-space fil
Tahoe's SFTP frontend includes several workarounds and extensions to make it function correctly with sshfs.
Mutable parts of a filesystem should only be accessed via a single sshfs mount (this is a stronger restriction than the [write coordination directive](http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/write_coordination.html) against writing mutable parts of a filesystem via more than one gateway). Data loss may result for concurrently accessed files if this restriction is not followed.
When writing a file to the Tahoe filesystem, sshfs does not wait for the 'close' request to complete before reporting to the application that the file has been successfully closed (#1059). Therefore, you should not shut down your gateway node immediately after writing files via sshfs, otherwise those files may be lost. It is possible that an upload could fail (due to a network error, lack of storage space, etc.); such failures will not be reported to applications using sshfs. This also implies that during the upload, a file could be visible via SFTP but not via the Tahoe WUI, CLI, or FTP frontends.
([This patch](http://allmydata.org/trac/tahoe-lafs/raw-attachment/wiki/SftpFrontend/sshfs.c.patch) makes sshfs wait for close requests to complete, but may cause its own compatibility problems; the patch is provided only for testing purposes.)