tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tramp never unmounts sshfs volumes


From: Michael Albinus
Subject: Re: Tramp never unmounts sshfs volumes
Date: Mon, 04 Oct 2021 15:26:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

Hi Stephen,

>>>   > 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
>>>
>>>   Yes, you can always shoot yourself in the foot. It might be possible to
>>>   check this case, but is it really worth the effort?
>>
>> I do not need this fixed.  Tramp sshfs is very useful to me as-is.  But I
>> wonder if in general it would be good for Tramp to be robust against dying
>> network connections.
>
> There are also other connection types which will suffer from two Emacs
> sessions in parallel. No need to fix this.
>
> However, it is is different if a network connection is dying. I will
> work on this scenario next days.

I have prepared a patch for this, see appended. Could you pls test?

There is a new defconst `tramp-fuse-mount-timeout', which defines the
time period how often it is checked whether an fuse volume is still
mounted. I didn't want to perform the check every time the volume is
accessed, this would result in severe performance penalties.

The initial value of the defconst is derived from
`remote-file-name-inhibit-cache' (10 seconds). Like that variable, it
could also be nil (never check the mount) or t (always check the mount).

I'm kind of undecided whether this shall be a defcustom, but somehow I
have the feeling it would be over-engineering. The defconst is there
just in case ...

>>  < Stephen

Best regards, Michael.

Attachment: txtwb62Q32oxB.txt
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]