Changes between Version 3 and Version 4 of SftpFrontend


Ignore:
Timestamp:
2010-05-28T22:44:26Z (14 years ago)
Author:
davidsarah
Comment:

wrong ticket number #1045 -> #1041. also reference #1059

Legend:

Unmodified
Added
Removed
Modified
  • SftpFrontend

    v3 v4  
    66=== General compatibility issues ===
    77
    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 #1045). This is known to be a problem for at least the WinSCP client, which has a close timeout of 15 seconds.
     8Before 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.
    99
    1010
     
    1515Tahoe's SFTP frontend includes several workarounds and extensions to make it function correctly with sshfs.
    1616
    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.)
     17sshfs 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.)
    1818
    1919Some 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.