> On Nov 3, 2019, at 5:36 AM, Michael Albinus <[email protected]> wrote:
>
> JD Smith <[email protected] <mailto:[email protected]>> writes:
>
> Hi,
>
>> Tramp (2.3.5.26.2) commonly hangs my Emacs session in the following
>> scenario:
>>
>> * On an internal network at my work, I visit a file via:
>>
>> * /ssh:someinternalpath.foo.bar:file
>>
>> * I continue to edit the file after leaving the internal network.
>> * Later, on another network (at home, etc.) Tramp can no longer access
>> the file via someinternalpath.foo.bar. File operations, write
>> attempts, etc. hang as Tramp tries in vain to reach the host via a
>> no longer reachable hostname/path.
>> * The various `tramp-cleanup-*` commands do nothing for this problem,
>> since they assume the host is still reachable via the original
>> hostname, and merely reset the cached information.
>> * I can at this point kill the buffer (or Emacs, if hung), and visit
>> the file using
>>
>> * /ssh:hopserver.bar.baz|ssh:someinternalpath.foo.bar:file
>>
>> * but there is no way to save or write the changes in my local buffer.
>> So this often hangs Emacs and loses the changes.
>
> So why doesn't work
>
> M-x tramp-cleanup-all-connections
> C-x w ;; in a remote buffer
>
> The second command, write-file, should ask you for a new file name. This
> includes editing the host name.
Because even after cleanup, C-x w hangs Tramp irrecoverably. It could be this
relates to my use of ido-write-file, which may probe the host for filename
info. In the future I’ll try M-x write-file followed by C-g C-f to disable
ido’s file completion niceties and see if I can recover. Often however nothing
will unfreeze Emacs after this hang occurs (even a pkill -USR2 Emacs).
>> Is there some what to effect a `tramp-reset-host` so that a buffer
>> will be marked as no longer visiting any file, and will re-prompt you
>> for a filename so you can write your changes?
>
> No, such a command does not exist. There is the danger that if you have
> a modified buffer, and you remove the buffer-file-name, this buffer is
> not covered by auto-save, nor by "C-x s" (save-some-buffers), nor by
> "C-x C-c" (save-buffers-kill-terminal). I, for example, count on this
> behavior, because I'm notorious in *not* saving buffers.
I certainly see that such a “detached” modified buffer could be dangerous.
Though having unsaved changes that can’t be written without hanging Emacs is
also quite problematic. Some of this may be an unfortunate interaction between
ido and Tramp.
>> Or perhaps a `tramp-change-hostpath` so you can re-enter the (possibly
>> multi-hop) host path to the file?
>
> That's a good idea. Will see how to implement it. It shall be a bulk
> renaming, for all buffers related to the respective host.
>
> The bulk renaming shall be only for the remote part of a file name,
> including existing multi-hops. For the local part, we cannot assume that
> a file is located at the very same location on the other host. So Emacs
> must go through all related buffers, and offer to edit the new file
> name, with the default "/method:newhost:/same/path/to/file".
> WDYT?
I think that would work well, especially for the common case of visiting
multiple files on the now inaccessible host. I wonder if it would it be
possible to first test if the local path on newhost remains valid and reuse it,
rather than just prompting to edit localpath in all related buffers? Perhaps a
buffer local `possible-new-host` var? Then, on any file access, try it. If it
succeeds, update the buffer filename and clear possible-new-host. If it fails,
prompt the user for another local filename.
I guess the concern there could be that localpath is writeable, but still
wrong, and Tramp wouldn’t know. So alternatively, perhaps the bulk rename
could apply to the remote part and any matching stem prefix of the local part,
e.g. if I’m visiting two files:
/method:badhost:/path/to/a.txt
/method:badhost:/path/from/b.txt
I could M-x tramp-bulk-rename-hostpath
from: /method:badhost:/path
to: /method:hophost|method:goodhost:/other/path
If you do this incorrectly, you could have unwritable filepaths, but that’s the
situation you were already in, so you are no worse off!
Thanks for considering.
Best,
JD
