13

I just started using emacs last week and everything is going well so far. I am using tramp to edit remote files as follows:

C-x C-f
/ssh:user@server:/file/to/edit

I login to the server using an ssh key, so no password is needed. Therefore I don't do anything special to start tramp and nothing has been added to my .emacs file, I simply type the above in my local emacs and it works.

The files im editing are mostly python (ie: plain text *.py files) and for the most part everything works correctly. However when I try to open some files they don't open and the following message is displayed:

gzip: stdin: unexpected end of file

Is there any way to get around this issue?

UPDATE: As suggested in the comments I enabled (setq tramp-verbose 6). The tramp debug buffer is huge (thousands of lines) so I have tried to pick out the parts that appear to be important or where some sort of error is mentioned, hopefully that will aid in figuring out what is happening:

16:11:29.124528 tramp-sh-handle-file-local-copy (3) # Encoding remote file `/ssh:myuser@myserver:/path/to/python/file.py' with `(gzip <%s | base64)'...done


16:11:29.130875 tramp-sh-handle-file-truename (4) # Finding true name for `/ssh:myuser@myserver:/path/to/python/file/'


16:11:29.131565 tramp-send-command (6) # \readlink --canonicalize-missing /path/to/python/file/ 2>/dev/null; echo tramp_exit_status $?
16:11:29.376133 tramp-wait-for-regexp (6) #

16:11:33.245252 tramp-sh-handle-file-local-copy (3) # Decoding local file `/tmp/tramp.4885Mau.py' with `(lambda (beg end) (base64-decode-region beg end) (let ((coding-system-for-write (quote binary)) (coding-system-for-read (quote binary))) (apply (quote call-process-region) (point-min) (point-max) (car (split-string gzip -d)) t t nil (cdr (split-string gzip -d)))))'...done
16:11:33.249827 tramp-call-process (6) # `chown 1000:1000 /tmp/tramp.4885Mau.py' nil nil
16:11:33.252963 tramp-call-process (6) # 0
16:11:33.255820 tramp-handle-insert-file-contents (3) # Inserting `/ssh:myuser@myserver:/path/to/python/file.py'...done


///b47a60d20b86781fc5d02f0fac35ec59#$16:11:34.975322 tramp-send-command-and-check (1) # File error: Couldn't find exit status of `( (test -e /path/to/python/file.py || test -h /path/to/python/file.py) && \stat -c '(("%N") %h %ue0 %ge0 %Xe0 %Ye0 %Ze0 %se0 "%A" t %ie0 -1)' /path/to/python/file.py || echo nil)'

The last line appears to be the actual error.

darkpool
  • 231
  • 1
  • 4
  • Show us such a file, or at least the end of it? Can you unzip it with no problem if you do that outside Emacs? – Drew Dec 14 '16 at 16:54
  • It is just a regular python text file. I presume when accessing it with tramp, it automatically gets zipped to allow for a smaller transfer size. It won't be of much help to post any of the python files because they are all quite large (over 100 lines of code). But in the end, they are just plain text python files. One thing to not is, the files were originally on my local machine and I used sftp to upload them to the server. Not sure if that matters. – darkpool Dec 14 '16 at 18:06
  • 2
    Does the problem go away if you increase the value of `tramp-inline-compress-start-size` to something big like 1000000? – nispio Dec 14 '16 at 19:24
  • Thanks @nispio that did the trick. Seems to be working now. Out of interest, what is the difference between your suggestion and tramp-copy-size-limit? It seems like perhaps that might have also been a solution, or not? – darkpool Dec 15 '16 at 06:37
  • 3
    We haven't actually fixed your problem, just shown that it is probably a problem with tramp's inline compression. If the files are big enough (larger than `tramp-inline-compress-start-size`) then tramp compresses the data on the server side and decompresses it on the client side. This only applies to files that are larger than `tramp-inline-compress-start-size` but smaller than `tramp-copy-size-limit`. – nispio Dec 15 '16 at 15:49
  • ok, so as long as my files are smaller than tramp-inline-compress-start-size then they will not be compressed during the transfer which is why everything appears to be working fine? I guess as a temporary solution that is ok since I doubt many of my code files will get bigger than what I have set ie: 1000000. I do not have anything set for tramp-copy-size-limit, not sure if I should. – darkpool Dec 16 '16 at 04:58
  • Apply `(setq tramp-verbose 6)` and rerun your test, w/o setting `tramp-inline-compress-start-size`. There will be a Tramp debug buffer, which you might show us. This should give the details of your problem. – Michael Albinus Dec 16 '16 at 09:57
  • Thanks @MichaelAlbinus and nispio for your help. I have posted a snippet of my tramp debug. Hopefully that helps. – darkpool Dec 17 '16 at 14:55
  • Where did you post the snippet? – Michael Albinus Dec 17 '16 at 18:58
  • At the bottom of the original question. – darkpool Dec 17 '16 at 19:25
  • Thanks, I needed to refresh the page. However, what you have posted is incomplete, and it doesn't tell anything. The last visible command is `readlink --canonicalize-missing ...`, and afterwards there is an error message about `( (test -e /path/to/python/file.py || ...`. This doesn't fit. Please provide the full debug buffer, via pastebin or via email to the Tramp devel mailing list (or directly to me, if you prefer). – Michael Albinus Dec 18 '16 at 08:19
  • I was encountering this error - It turns out the issue was that I did not have read permission on some files, and that message "File is not readable: " was not being gzipped so that the client could un-gzip it. (emacs-version 26.1) – Marvin Aug 23 '19 at 14:49

1 Answers1

11

I had a similar problem when trying to open/save plain ASCII files via tramp's sftp: the files were fine, I was able to edit them with, for example,nano, but trying to open them via tramp would get rejected with the rather cryptic message: invalid string format.

This was probably related to inlining and compression, because changing those solved the issue for me. This is what I've done, using the UI:

  1. M-x customize-mode RET tramp-mode
  2. Set Tramp Copy Size Limit and Tramp Inline Compress Start Size to a very high number (1000000 in my case) to avoid out-of-the band and/or compressed data transfer. Note that, unlike the OP, I had to change both of them to get it to work. Again, this means it only works for inline, uncompressed transfer but as for the OP, this is more than enough for me since I just want to remotely edit fairly small ASCII files with the best editor that exists.

Just wanted to post it in case somebody runs into the same issue, because googling the error message didn't bring any useful results and it took me a while to figure out that it was related to the file's size (which lead me to this post). If you need additional infos or log files to solve the issue feel free to ask, but I believe you would be able to reproduce it by narrowing the above mentioned variables.

Cheers! Andres

fr_andres
  • 211
  • 2
  • 5