|
From: | Guillaume Demeyère |
Subject: | Re: Copy-paste of large files from Windows to Linux - base64 issue? |
Date: | Tue, 14 Jan 2020 15:48:05 +0100 |
Guillaume Demeyère <address@hidden> 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.
tramp-2.4.3-debug-2020-01-14.log
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |