sshfs: Update to 3.5.1

1 files changed, 41 insertions, 1 deletions

diff --git a/pkg/sshfs/sshfs.1 b/pkg/sshfs/sshfs.1
index c5eecb9e..20d3d827 100644
--- a/pkg/sshfs/sshfs.1
+++ b/pkg/sshfs/sshfs.1
@@ -145,6 +145,10 @@ for some additional information. Possible values are:
 Emulate overwriting an existing file by deleting and
 renaming.
 .TP
+.B renamexdev
+Make rename fail with EXDEV instead of the default EPERM
+to allow moving files across remote filesystems.
+.TP
 .B truncate
 Work around servers that don\(aqt support truncate by
 coping the whole file, truncating it locally, and sending it
@@ -156,6 +160,10 @@ using \fIstat\fP instead.
 .TP
 .B buflimit
 Work around OpenSSH "buffer fillup" bug.
+.TP
+.B createmode
+Work around broken servers that produce an error when passing a
+non\-zero mode to create, by always passing a mode of 0.
 .UNINDENT
 .TP
 .B \-o idmap=TYPE
@@ -278,7 +286,15 @@ workaround=rename\fP\&. However, in this case it is still possible that
 someone (or something) recreates the destination file after SSHFS has
 removed it, but before SSHFS had the time to rename the old file. In
 this case, the rename will still fail.
-.SS SSHFS hangs
+.SS Permission denied when moving files across remote filesystems
+.sp
+Most SFTP servers return only a generic "failure" when failing to rename
+across filesystem boundaries (EXDEV).  sshfs normally converts this generic
+failure to a permission denied error (EPERM).  If the option \fB\-o
+workaround=renamexdev\fP is given, generic failures will be considered EXDEV
+errors which will make programs like \fImv(1)\fP attempt to actually move the
+file after the failed rename.
+.SS SSHFS hangs for no apparent reason
 .sp
 In some cases, attempts to access the SSHFS mountpoint may freeze if
 no filesystem activity has occured for some time. This is typically
@@ -286,6 +302,30 @@ caused by the SSH connection being dropped because of inactivity
 without SSHFS being informed about that. As a workaround, you can try
 to mount with \fB\-o ServerAliveInterval=15\fP\&. This will force the SSH
 connection to stay alive even if you have no activity.
+.SS SSHFS hangs after the connection was interrupted
+.sp
+By default, network operations in SSHFS run without timeouts, mirroring the
+default behavior of SSH itself. As a consequence, if the connection to the
+remote host is interrupted (e.g. because a network cable was removed),
+operations on files or directories under the mountpoint will block until the
+connection is either restored or closed altogether (e.g. manually).
+Applications that try to access such files or directories will generally appear
+to "freeze" when this happens.
+.sp
+If it is acceptable to discard data being read or written, a quick workaround
+is to kill the responsible \fBsshfs\fP process, which will make any blocking
+operations on the mounted filesystem error out and thereby "unfreeze" the
+relevant applications. Note that force unmounting with \fBfusermount \-zu\fP, on
+the other hand, does not help in this case and will leave read/write operations
+in the blocking state.
+.sp
+For a more automatic solution, one can use the \fB\-o ServerAliveInterval=15\fP
+option mentioned above, which will drop the connection after not receiving a
+response for 3 * 15 = 45 seconds from the remote host. By also supplying \fB\-o
+reconnect\fP, one can ensure that the connection is re\-established as soon as
+possible afterwards. As before, this will naturally lead to loss of data that
+was in the process of being read or written at the time when the connection was
+interrupted.
 .SH MOUNTING FROM /ETC/FSTAB
 .sp
 To mount an SSHFS filesystem from \fB/etc/fstab\fP, simply use \fBsshfs\(ga