tramp-devel
[Top][All Lists]
Advanced

[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: 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

Hi Michael,

Thank you for your explanations!

I tried setting tramp-chunksize to 100, and then to 50. I still got the same error, although I did see the file getting sent in numerous chunks in the logs.

So I installed tramp 2.4.3 from GNU ELPA and re-did the same test (without setting tramp-chunksize). The log gets huge and I am getting lost in it. Here it is.

Regards,

Guillaume


Michael Albinus <address@hidden> escreveu no dia terça, 14/01/2020 à(s) 11:10:
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.

Attachment: tramp-2.4.3-debug-2020-01-14.log
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]