0

I get a weird bug and I am struggling to fix it.

The problem occur only when writing files over 2900 characters through ssh with tramp. The file is correctly sent in remote machine, but tramp-perl-decode-with-module hangs after saving the file. Here is the message where it hangs:

Decoding remote file '/plink:Session1:/home/user1/file' using 'tramp_perl_decode_with_module >%s'

It's strange because opening a file over 2900 characters is working fine (which use the same tramp-perl-decode-with-module method). and the file is correctly updated when I check it with on the remote machine. The only difference I noted is that the file lost is +x flag. I guess the problem occur at this stage.

That "2900" is so arbitrary precise that it should be a key of the answer. Apparently there was a bug in emacs when writing files with lines over 2900 characters, maybe there is a problem with windows changing the encoding and the newline characters are changed. But I checked with different encoding utf8-xxx and the problem still occurs. I don't know what else to do.

Tramp default method is set to plink, and use the session set in putty. I tried to use ssh since I have the binaries with no success unfortunately, it can't even connect to the remote machine.

If you know a workaround within emacs, what I do is saving file, chmod +x in remote then opening again in emacs. Or just use vim in remote machine. But it messing my workflow quite a bit. Having to deal with 2900 characters limitation for scripts is somewhat cool, but it's quite frustrating as well.

Improve this question
4
  • Note that you have misinterpreted the description of the problem you found on the mailing list. The problem is that emacs hangs when there are lines that are 2900 characters long, it is that emacs has often been very slow (even appearing to hang), when there are very long lines in the file you are editing. That particular file had some lines that were 2900+ characters long, but the specific number is just a coincidence.
    – db48x
    Commented Apr 28, 2022 at 10:09
  • As for solving your problem, are you sure that it has hung and is not merely taking a long time? What version of Emacs are you using? Have you made sure that you have the most recent version of PuTTY (and therefore of Plink as well)?
    – db48x
    Commented Apr 28, 2022 at 10:10
  • 1
    Hard to analyze with the given data. I recommend to write a Tramp bug report via M-x tramp-bug.
    – Michael Albinus
    Commented Apr 28, 2022 at 11:00
  • Well, after some try, I conclude that the problem is on the remote machine because there is no problem with others. Still checking. I'm letting emacs doing the decode for up to 10 minutes for now. Still not working. But still I guess it's not emacs nor tramp fault. Not sure if it's relevant to try to solve this here. Sorry for the inconvenience. My guess is that there is an outdated perl binaries in remote machine during the tramp-perl-decode-with-module or something like that. At least I know that everything is fine in emacs.
    – samd854587
    Commented Apr 28, 2022 at 12:02

1 Answer 1

Reset to default
0

Well, I finally took the time to look after that issue.

First, the workaround was pretty simple, I decreased the tramp-copy-size-limit to 2000 only to make tramp avoid using the inline method that was "hanging" and use the external method instead (here psftp, on windows, who worked fine)

Didn't find the exact reason behind unfortunately but it is certainly due to an old machine.

Turns out that the machine on which I try to upload files have an ARG_MAX set to 30,720 only (usually over 2,000,000 on recent system)

$ getconf ARG_MAX
   30720

Maybe it is just that the command used in the inline method was too long? At the end my issue is solved.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.