Guillaume Demeyère <[email protected]> writes: > Hi Michael,
Hi Guillaume, > I really think that I edited the file correctly, in order to make it > less huge. And I appreciate it. But often, every single trace line counts in order to follow the work of Tramp when debugging. > Here's an unedited version (5.3 MB) run this morning, so you can make > sure I did. Thanks. This is pretty good for analysis. First, I've checked the encoded data. They have decoded fine into a Javascript file, so it isn't a problem of base64 I'm confident. Following the traces, Tramp has done its work until the end of the tramp-send-string function. Likely, an error happened in the final process-send-string call. There is a known Emacs problem, that sometimes it fails to send a very large string at once. For this reason, we have the tramp-chunksize variable. Please set it to a proper value (say, 100 or 50), and repeat your test. If this doesn't help, we must know which error happens. The progress reporter for copying a file in Tramp hides this, we only see "Decoding remote file `/plink:nxuser@vdemopro892dsy:/home/nxuser/Documents/1.bundle.js' using `base64 -d -i >%s'...failed". Newer Tramp versions tell us the real error in such a case, when tramp-verbose is 10. Could you please install the recent Tramp 2.4.3 from GNU ELPA, and try this? Send the trace file (this case, w/o base64 data might be sufficient). Finally, you could of course avoid the whole trouble by using pscp instead of plink. But this wouldn't help to catch the problem :-) > Best regards, > > Guillaume Best regards, Michael.
