Trying here to download (scp file from remote to local) that was considered large file, then Emacs tried to compact it, then got stuck.

Even used scp command to do it because copying via ssh got stuck too.

Now there are two goals here: one is repair file copy from remote to local via ssh or set it to do not compact large files for copy via scp on TRAMP mode, but copy it at normal size.

Any ideas?

  • If scp without Emacs is failing, it doesn't seem likely that Emacs will fare any better. I would try to debug the first issue.
    – phils
    Oct 22, 2019 at 3:25
  • Tramp's internal scp command does not compress. I recommend to set tramp-verbose to 6, and check the resulting debug buffer for the commands Tramp has used. Search for lines containing (6). Oct 22, 2019 at 7:59
  • Already set tramp-verbose 6, but application stucks when starting compression, then can't reach the log buffer. How the logs could be accessed? scp e ssh works just fine out of Emacs, only stucks while compressing.
    – Emmett44
    Oct 22, 2019 at 12:14
  • Just a blind shot: set tramp-inline-compress-start-size to nil. Oct 23, 2019 at 7:47
  • And how would that be done?
    – Emmett44
    Oct 23, 2019 at 21:57

2 Answers 2


TRAMP uses itself Base64 encoding, it doesn't hangs, just takes a really long time for larger files.

Maybe rsync or rcp methods speeds up the process, but this is its basis.

What may be done is run a shell command in minibuffer, via M-!, then enter scp as outside of Emacs, and without using TRAMP mode, it would accelerate it significantly, with regular scp speed.


Try stablishing connection using scp itself instead of ssh, as of /scp:user@host#port:/directory, and then using scp again, as managed here to don't use base64 conversion, which seems to be slowing the transfer.

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.