@Robert Paasche
I see.
Does your FTP server use Linux or Windows?
Something must have been stuck in RAM because after a PC reboot the success
rate (still in binary mode) with your very first tip (">=0" instead of ">0") is
a lot higher. It's still not even close to acceptable though:
With a
No never used with images.
//length was "*2" but why?
That is for an buggy ftp-server, which mishandled multibyte encodings. On
UTF-16 Files he has reported the number of chars instead of bytes, so the
file size was just the half erverytime.
fos.write(data);
this should be something like:
@Robert Paasche
The code is used in an AsyncTask and there's more error handling to it
(including proper error messages,...), I just simplified it. ;)
Have you ever tested it with images too? Text files always seem to download
properly (no matter what size), it's just the images that are
@ julia.ruzicka
content is just a simple POJO holding the byte and meta data (like
timestamps). In some situations I'm using a fileoutputstream after
disconnecting from ftp. I'm downloading large (>300 mb) zip-Files.
Am Do., 4. Juni 2020 um 14:10 Uhr schrieb Julia Ruzicka <
@Robert Paasche
At first I tried to do it with a `FileOutputStream` and
`ftpClient.retrieveFile(fileName,fos)` but that's how I noticed the problem. I
then switched to using ` InputStream is =
ftpClient.retrieveFileStream(filename)` and when that didn't work properly
either, I added `
