Changes between Version 3 and Version 4 of SftpFrontend
- Timestamp:
- 2010-05-28T22:44:26Z (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SftpFrontend
v3 v4 6 6 === General compatibility issues === 7 7 8 Before uploading a file to a Tahoe filesystem, the whole file has to be available. This means that the upload can only start when the file has been closed in the SFTP session. Particularly when writing large files, the client may time out between sending the close request and receiving the response (ticket #104 5). This is known to be a problem for at least the WinSCP client, which has a close timeout of 15 seconds.8 Before uploading a file to a Tahoe filesystem, the whole file has to be available. This means that the upload can only start when the file has been closed in the SFTP session. Particularly when writing large files, the client may time out between sending the close request and receiving the response (ticket #1041). This is known to be a problem for at least the WinSCP client, which has a close timeout of 15 seconds. 9 9 10 10 … … 15 15 Tahoe's SFTP frontend includes several workarounds and extensions to make it function correctly with sshfs. 16 16 17 sshfs does not wait for 'close' requests to complete before reporting to the application that a file has been successfully closed . 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. ([http://allmydata.org/trac/tahoe-lafs/raw-attachment/wiki/SftpFrontend/sshfs.c.patch This patch] makes sshfs wait for close requests to complete, but may cause its own compatibility problems; the patch is provided only for testing purposes.)17 sshfs does not wait for 'close' requests to complete before reporting to the application that a 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. ([http://allmydata.org/trac/tahoe-lafs/raw-attachment/wiki/SftpFrontend/sshfs.c.patch This patch] makes sshfs wait for close requests to complete, but may cause its own compatibility problems; the patch is provided only for testing purposes.) 18 18 19 19 Some applications may make assumptions that are incompatible with Tahoe. For example, 'flushing' a file does not guarantee that written data is reflected in the Tahoe filesystem, so opening the same file via another handle and attempting to read that data will not work.