GNU bug report logs -
#36809
"~nosuchuser" commit breaks tramp's scp
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 25 Jul 2019 17:12:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36809 in the body.
You can then email your comments to 36809 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Thu, 25 Jul 2019 17:12:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 25 Jul 2019 17:12:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 12:10:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 36809 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 12:55:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 36809 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 13:19:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 36809 <at> debbugs.gnu.org (full text, mbox):
Yuri D'Elia <wavexx <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 14:13:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 36809 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 17:07:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 36809 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36809
; Package
emacs
.
(Fri, 26 Jul 2019 18:11:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 36809 <at> debbugs.gnu.org (full text, mbox):
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 <at> cs.ucla.edu). Please give the
> new master a try, and thanks for reporting the problem.
Looks good now!
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sat, 03 Aug 2019 20:36:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
bug acknowledged by developer.
(Sat, 03 Aug 2019 20:36:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 36809-done <at> debbugs.gnu.org (full text, mbox):
Yuri D'Elia wrote:
> Looks good now!
Thanks for checking; closing the bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 01 Sep 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 291 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.