[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183190#comment-17183190
]
JRRR commented on NET-686:
--------------------------
Sorry for the late reply (vacation).
There are simply bytes missing in seemingly random places (usually in the
second half of the file), which completely "breaks" image files but doesn't
have too much of an impact on text files (apart from content missing obviously).
Some files do seem to break more often than others (e.g. example image "2a")
but if I run the same download command with the same files multiple times, I'll
always get different results: Not every file is corrupt every time it's
downloaded, one time it's okay, then it's corrupt the next three or maybe even
five times and when it is, the amount of missing bytes also varies. It does
seem to happen more often with images than with txt files though and if I use a
big byte buffer, it happens more often than with a small one. At one point I
was also pretty sure that files downloaded from one of the servers resulted in
more corrupted files (compared to the other one) and today the Windows server
was the "problem child" but I can't remember if it was always that one.
I uploaded examples (the original files I found on google) that I just
downloaded: 4/4 images and 1/2 text files were corrupt.
* "retrieveFileStream" version
* Only `InputStream`/no `BufferedInputStream`
* Big byte buffer (`singleFile[0]`.getSize())
* Moved "setFileType"
A smaller buffer (5000) resulted in 2/4 corrupted images and 2/2 corrupted text
files at first. The second time I ended up with 2/4 corrupted images and 0/2
corrupted text files.
With a buffer size of 1000 all 6 files were okay but if I ran it multiple
times, there'd still be a corrupt file at one point, so I can't just rely on
that.
> Most files aren't downloaded completely from an FTP server
> ----------------------------------------------------------
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.6
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
> Reporter: JRRR
> Priority: Major
> Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png,
> 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java
>
>
> About a month ago I opened another
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files
> randomly missing bytes. It looks like the download always "completes" and
> there are no error messages/exceptions but random bytes in random files are
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe
> 40, bytes smaller than the original), and are then also visibly corrupt, than
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK
> 24, target SDK 27), which I'm testing with FTP servers in the same network
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what
> method in the library I use (retrieveFile, retrieveFileStream,
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have
> a lot of time because those servers regularely delete uploaded files, I never
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using
> Java's default "Socket" but I still had the same problem on Android Studio's
> simulator/a real device. BUT: When I used the same code to create a small
> Windows/Swing/Java app, there were no more corrupted files.
> It looks like this bug is only affecting a very specific combination of
> OS,...:
> Android (emulator/real device) + Java (8) + FTP server in the same network
> (accessed via IP)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
