[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Copy-paste of large files from Windows to Linux - base64 issue?
From: |
Michael Albinus |
Subject: |
Re: Copy-paste of large files from Windows to Linux - base64 issue? |
Date: |
Tue, 14 Jan 2020 11:10:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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.