GNU bug report logs -
#60534
28.2; Forbidden reentrant call of Tramp
Previous Next
Full log
Message #16 received at 60534 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> In order to understand the problem, let's assume the following scenario:
>
> - You have connected to a remote host, say "/ssh:host:". Tramp uses
> internally the process *tramp/ssh host* for communicating with that
> process.
>
> - You have also started another asynchronous process to that remote
> host.
>
> - Now, while normal use of Emacs, the function (file-attributes
> "/ssh:host:/path/to/file") is called. Tramp sends a command to the
> process *tramp/ssh host*, like "stat /path/to/file".
>
> - While Tramp waits for the answer of the "stat ..." command, your other
> process has finished. It might have a process sentinel, which is
> called exactly at this time, because Tramp is in a loop
> (accept-process-output ...).
>
> - This process filter might trigger another file operation, like
> (delete-file "/ssh:host:/tmp/tmpfile"). This would require to send
> another command to the *tramp/ssh host* process like "rm -f /tmp/tmpfile".
>
> - Since the first command, "stat ...", hasn't been finished, this would
> result in inconsistencies. Tramp detects this situation, and raises
> the "Forbidden reentrant call of Tramp" error.
>
> Not so easy to solve. Ideally, remote file name functions initiated in
> process filters, process sentinels, timers and alike shall wait, until
> the currently executed remote command has finished. Don't know how to
> achieve this.
(This may be an ignorant question, but) if that's so, is it possible to
open a separate connection (perhaps with a ControlPath suffix, and
ControlPersist-ed) in the place of the "Forbidden reentrant call"?
Regards,
James
This bug report was last modified 175 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.