Re: Tramp never unmounts sshfs volumes

[Stephen Gildea]

Michael Albinus <michael.albinus@gmx.de> wrote:

>   > 3. Unmount if this process did the mount.  This is your idea of an
>   > "unmount on cleanup" bit.  As with case 2, if this process did not do
>   > the mount, Tramp would have to handle an unexpectedly closed connection.
>   >
>   > 4. Every Emacs uses its own mount point.  Multiple mount points could
>   > still share an ssh connection but would no longer share the sshfs cache.
>   > This option seems the simplest and cleanest to implement.
>   
>   I'm just working on 3, controlled by a user option. Let's see how it
>   goes (with your testing), if not satisfying we'll have 4.
>   
>   Variant 4 has the disadvantage to leave several mount points when Emacs
>   crashes or does not pass the cleanup machinery for whatever reason.

I tested the patch you sent me that implements variant 3.

tramp-cleanup-this-connection fails to unmount.  The problem is that
vec is not a member of tramp-fuse-mount-points:
    vec:
    (tramp-file-name sshfs nil nil otherhost nil /home/gildea/ nil)
    tramp-fuse-mount-points:
    ((tramp-file-name sshfs nil nil otherhost nil /home/gildea/afile nil))

tramp-cleanup-all-connections and exiting Emacs both do unmount, as expected.
However, they leave behind the mount point directory, 
/tmp/tramp.sshfs.otherhost/

Two Emacs processes accessing the same remote host can confuse each other:
   . open an sshfs file in Emacs 1
   . open an sshfs file in Emacs 2 on the same remote host
   . cleanup-all in Emacs 1
   . try to access file again in Emacs 2 - fails: No such file or directory


Also while testing I came across two behaviors that could be better.
These are not regressions, as un-patched Tramp behaves the same.


If I open a non-existent file, e.g.,
/sshfs:otherhost:/tmp/newfile
The following gets logged to *Messages*
File is missing: Opening input file No such file or directory 
/tmp/tramp.sshfs.otherhost/tmp/newfile
and the buffer is shown as editing the local file 
/tmp/tramp.sshfs.otherhost/tmp/newfile


Tramp will not share the ssh connection with an existing connection to
the remote host, because it uses its own ControlPath.  This makes it
harder to use Tramp with a remote host that requires user action to
authenticate, as many two-factor methods do.  I would prefer that
Tramp not set its own options and let the options in my .ssh/config
control the connection.