[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1059: sshfs does not wait for an FX_CLOSE request to complete before reporting success from the close

[Tahoe-LAFS]

#1059: sshfs does not wait for an FX_CLOSE request to complete before reporting
success from the close
-------------------------------------+-------------------------------------
     Reporter:  davidsarah           |      Owner:
         Type:  defect               |     Status:  new
     Priority:  major                |  Milestone:  undecided
    Component:  code-frontend-ftp-   |    Version:  1.6.1
  sftp                               |   Keywords:  sftp sshfs preservation
   Resolution:                       |  docs
Launchpad Bug:                       |
-------------------------------------+-------------------------------------
Changes (by warner):

 * component:  code-frontend => code-frontend-ftp-sftp


Old description:

> 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).

New description:

 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).

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1059#comment:4>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage