Re: tramp (2.6.0-pre nil/nil); buffer modification prevented if tramp connection can not be restablished

[Michael Albinus]

Deeno CO <deenoco@gmail.com> writes:

Hi,

> Somewhere, or some versions, between emacs+tramp on ubuntu 20.04 and
> emacs+tramp describred below running on MacOS there is a change in
> behaviour where I am prevented from _modifying_ a buffer if tramp can not
> re-establish the connection to the host.  Note that I am saying
> modifying not saving the buffer.  While eventually I do need to
> re-establish the connection to save to buffer unless I choose to save
> the buffer elsewhere.  Unfortately, in my current work environment
> various temporary network outages occur and I would just continue
> editing files then save when the connections can be re-established.  In
> the emacs+tramp verison described below, any attempted change to the
> buffer bring up an error buffer & message indicating connection failure
> and possibly resolution by one of the tramp cleanup connecition
> commands buf cleaning up the connection is not a solution and next
> attempted change to the buffer starts the cycle over again.

Since Emacs 28, Tramp supports file locks. That is, such a file lock is
created when you start to modify a buffer visiting a file. Per default,
the file lock is written into the same directory the buffer's file is
located; that's why Tramp tries to connect the respective remote host.

You can change the location of such remote file locks via variable
`lock-file-name-transforms'. Or you can set variable
`remote-file-name-inhibit-locks’ to a non-nil value, which prevents file
locks for remote file names at all.

Best regards, Michael.