tahoe-lafs/trac-2024-07-25

sshfs does not wait for an FX_CLOSE request to complete before reporting success from the close #1059

New issue

Open

opened 2010-05-28 22:42:46 +00:00 by davidsarah · 3 comments

davidsarah commented

2010-05-28 22:42:46 +00:00

Owner

sshfs does not wait for 'close' requests on a file opened for writing to complete, before reporting to the application that a file has been successfully closed.

If the client attempts to reopen the same file via SFTP, we delay the open request until the previous upload has completed (successfully or not), so this does not normally cause visibly incorrect behaviour.

However, if the upload fails, sshfs has no way to report the failure (even though we do correctly return an error from the close request). So written data may be lost if the gateway is shut down, or there is a network error, lack of storage space on the grid, etc.

It is possible to patch sshfs to wait for the close reponse, but this may cause different problems, for example timeouts in applications along the same lines as #1041. Another possibility would be to store the written data at the gateway so that if it is shut down, it can restart the upload the next time it starts up (this is a variant on #935).

sshfs does not wait for 'close' requests on a file opened for writing to complete, before reporting to the application that a file has been successfully closed. If the client attempts to reopen the same file via SFTP, we delay the open request until the previous upload has completed (successfully or not), so this does not normally cause visibly incorrect behaviour. However, if the upload fails, sshfs has no way to report the failure (even though we do correctly return an error from the close request). So written data may be lost if the gateway is shut down, or there is a network error, lack of storage space on the grid, etc. It is possible to patch sshfs to wait for the close reponse, but this may cause different problems, for example timeouts in applications along the same lines as #1041. Another possibility would be to store the written data at the gateway so that if it is shut down, it can restart the upload the next time it starts up (this is a variant on #935).

tahoe-lafs added the

labels 2010-05-28 22:42:46 +00:00

tahoe-lafs added this to the undecided milestone 2010-05-28 22:42:46 +00:00

davidsarah commented

2010-05-28 22:45:25 +00:00

Author

Owner

Attachment sshfs.c.patch (693 bytes) added

Patch to make sshfs wait for files to be uploaded when they are closed.

**Attachment** sshfs.c.patch (693 bytes) added Patch to make sshfs wait for files to be uploaded when they are closed.

sshfs.c.patch

693 B

zooko commented

2010-05-30 04:59:18 +00:00

Author

Owner

Is this an issue we should report to http://fuse.sourceforge.net/sshfs.html ?

Is this an issue we should report to <http://fuse.sourceforge.net/sshfs.html> ?

tahoe-lafs added

code-frontend-ftp-sftp

and removed

code-frontend

labels 2014-12-02 19:42:55 +00:00

warner commented

2017-02-05 17:47:31 +00:00

Author

Owner

Note that a likely symptom of this bug (if the upload fails, perhaps because you do not have enough servers to meet the "shares of happiness" threshold), is that you wind up with zero-length files in your sshfs directory listing, which cannot be downloaded. I don't think these are tahoe-size entries: the SFTP frontend would report a 0-length file briefly (if you list the directory while uploading), but maybe sshfs frontends are caching the result and persisting in showing you a 0-length file even after tahoe has given up.