"~nosuchuser" commit breaks tramp's scp

"~nosuchuser" commit breaks tramp's scp

[Yuri D'Elia]

While testing today's build I noticed that tramp now hangs with the scp
method just after displaying 'tramp: Inserting <file>...done'.

A quick bisect revealed commit a5063aa8b174db286a0e83b8ffdd4e65c521f733
to be the culprit.

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Paul Eggert]

Yuri D'Elia wrote:

> While testing today's build I noticed that tramp now hangs with the scp
> method just after displaying 'tramp: Inserting <file>...done'.
> 
> A quick bisect revealed commit a5063aa8b174db286a0e83b8ffdd4e65c521f733
> to be the culprit.

Thanks for mentioning that. Since I don't use Tramp I'm afraid I can't reproduce 
the problem from this terse bug report. So I'm replying to bug-gnu-emacs (so 
that we get a bug report number for this) and ccing to Michael Albinus (so that 
our Tramp expert sees it).

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Yuri D'Elia wrote:
>
>> While testing today's build I noticed that tramp now hangs with the scp
>> method just after displaying 'tramp: Inserting <file>...done'.
>>
>> A quick bisect revealed commit a5063aa8b174db286a0e83b8ffdd4e65c521f733
>> to be the culprit.
>
> Thanks for mentioning that. Since I don't use Tramp I'm afraid I can't
> reproduce the problem from this terse bug report. So I'm replying to
> bug-gnu-emacs (so that we get a bug report number for this) and ccing
> to Michael Albinus (so that our Tramp expert sees it).

Like Paul, I'm not able to reproduce the problem. Using a build from
today with "emacs -Q", I apply "C-x C-f /scp::~nosuchuser". I get a
buffer "~nosuchuser" and the message "(New file)", which sounds OK. The
buffer's file name is "/scp:machine:/home/albinus/~nosuchuser", which is
also appropriate.

Yuri, could you pls describe in detail what you've done, and what has
failed?

Best regards, Michael.

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Yuri D'Elia]

On Fri, Jul 26 2019, Michael Albinus wrote:
> Like Paul, I'm not able to reproduce the problem. Using a build from
> today with "emacs -Q", I apply "C-x C-f /scp::~nosuchuser". I get a
> buffer "~nosuchuser" and the message "(New file)", which sounds OK. The
> buffer's file name is "/scp:machine:/home/albinus/~nosuchuser", which is
> also appropriate.

~nosuchuser has nothing to do with it.

I'm opening any file with the syntax /scp:machine:/fullpath and it gets
stuck just after "...done" is written. The file mode is irrelevant (any
file will do). I can escape with C-g, but barely anything works after
that (it's impossible to quit for example).

Any idea on how to investigate where is it stuck? (there's no error
being triggered).

Reverting the specific commit does fix the issue, which is strange.

I cannot reproduce the problem when starting with -Q, which is something
I'm going to investigate, but I'm still puzzled.

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Michael Albinus]

Yuri D'Elia <wavexx@thregr.org> writes:

Hi Yuri,

> I'm opening any file with the syntax /scp:machine:/fullpath and it gets
> stuck just after "...done" is written. The file mode is irrelevant (any
> file will do). I can escape with C-g, but barely anything works after
> that (it's impossible to quit for example).
>
> Any idea on how to investigate where is it stuck? (there's no error
> being triggered).

Usually, you set tramp-verbose to 6 (or to 10, if it is a really nasty
problem). There will be a debug buffer, for analysis.

Look for traces with level (1), these are errors. Traces with level (6)
are the commands sent to the remote host, and the returned output.

If you don't understand the traces, show them. I will try to investigate
(but I'm just starting a one week vacation, so I'll won't be too
reactive).

> Reverting the specific commit does fix the issue, which is strange.
>
> I cannot reproduce the problem when starting with -Q, which is something
> I'm going to investigate, but I'm still puzzled.

Same here, I cannot reproduce the problem.

Best regards, Michael.

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Yuri D'Elia]

On Fri, Jul 26 2019, Michael Albinus wrote:
>> Any idea on how to investigate where is it stuck? (there's no error
>> being triggered).
>
> Usually, you set tramp-verbose to 6 (or to 10, if it is a really nasty
> problem). There will be a debug buffer, for analysis.

Ok, this was helpful and it turned out that's actually something related
to this commit.

I have an unexpanded path based on user-emacs-directory which is
prepended to load-path:

  (concat user-emacs-directory "lisp/")

Somehow this now wreaks havoc when autoloading the 'editorconfig' elpa
package. I kept seeing this:

15:46:41.822312 tramp-do-file-attributes-with-stat (5) # file attributes with stat: /home/ydelia/~/.emacs.d/lisp/editorconfig-core.elc
15:46:41.822948 tramp-send-command (6) # ( (test -e /home/ydelia/\~/.emacs.d/lisp/editorconfig-core.elc || test -h /home/ydelia/\~/.emacs.d/lisp/editorconfig-core.elc) && ...
15:46:41.869461 tramp-wait-for-regexp (6) #

in the tramp log, which helped. Incidentally, this is only noticeable
when opening a remote directory even though the test path is local, for
a reason I didn't determine yet.

Note that editorconfig is actually located in ~/.emacs.d/elpa anyway.
~/.emacs.d/lisp is empty as I came to this point by culling everything
else in sight.

So, where's the issue? Something with regular ~ expansion which has
changed?

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Paul Eggert]

Yuri D'Elia wrote:
> Incidentally, this is only noticeable
> when opening a remote directory even though the test path is local, for
> a reason I didn't determine yet.

There was a bug in my recent changes to file-name-absolute-p. I fixed it on 
master (2019-07-26T16:46:18!eggert@cs.ucla.edu). Please give the new master a 
try, and thanks for reporting the problem.

I'm assuming that this bug was unrelated to Tramp's source code. Because 
file-name-absolute-p has always been system-dependent on names like "c://foo", 
Tramp does not assume that file-name-absolute-p can be applied usefully to 
remote file names.

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Yuri D'Elia]

On Fri, Jul 26 2019, Paul Eggert wrote:
> There was a bug in my recent changes to file-name-absolute-p. I fixed
> it on master (2019-07-26T16:46:18!eggert@cs.ucla.edu). Please give the
> new master a try, and thanks for reporting the problem.

Looks good now!

bug#36809: "~nosuchuser" commit breaks tramp's scp

[Paul Eggert]

Yuri D'Elia wrote:
> Looks good now!

Thanks for checking; closing the bug report.