JD Smith <address@hidden> 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 workM-x tramp-cleanup-all-connectionsC-x w ;; in a remote bufferThe second command, write-file, should ask you for a new file name. Thisincludes 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 havea modified buffer, and you remove the buffer-file-name, this buffer isnot 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 thisbehavior, 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 bulkrenaming, 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 thata file is located at the very same location on the other host. So Emacsmust go through all related buffers, and offer to edit the new filename, 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