Incomplete files uploaded, but no errors

Need help with FileZilla Client? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
mtcg
500 Command not understood
Posts: 3
Joined: 2016-07-15 16:11
First name: Mt
Last name: cg

Incomplete files uploaded, but no errors

#1 Post by mtcg » 2016-07-15 16:26

Hello:

With the latest version of FileZilla (3.19.0), we're able to duplicate on multiple Windows 10 workstations an issue in which files are uploaded with truncated text.

The ones in particular (perhaps incidentally) contain .aspx extensions. Filezilla reports nothing unusual in the upload, indicating they've done so successfully. But when I view these uploaded files on the server (a cloud-based Windows Server R2 hosted by Rackspace), the html in the files are incomplete.

Example:

Code: Select all

Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connection established, waiting for welcome message...
Status:	Logged in
Status:	Retrieving directory listing...
Status:	Calculating timezone offset of server...
Status:	Timezone offset of server is -14400 seconds.
Status:	Directory listing of "/" successful
Status:	Retrieving directory listing of "/testing"...
Status:	Directory listing of "/testing" successful
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connecting to 106.xxx.xx.xx:21...
Status:	Connection established, waiting for welcome message...
Status:	Connection established, waiting for welcome message...
Status:	Connection established, waiting for welcome message...
Status:	Connection established, waiting for welcome message...
Status:	Connection established, waiting for welcome message...
Status:	Connection established, waiting for welcome message...
Status:	Logged in
Status:	Logged in
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default3.aspx
Status:	Logged in
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default.aspx
Status:	Logged in
Status:	Logged in
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default021116.aspx
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default082015.aspx
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default1.aspx
Status:	Logged in
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default2.aspx
Status:	File transfer successful, transferred 6,758 bytes in 1 second
Status:	Starting upload of \\192.xxx.xxx.xxx\Web\Users\test-folder\test\testing\default082115.aspx
Status:	File transfer successful, transferred 3,389 bytes in 1 second
Status:	File transfer successful, transferred 4,886 bytes in 1 second
Status:	File transfer successful, transferred 3,609 bytes in 1 second
Status:	File transfer successful, transferred 7,100 bytes in 1 second
Status:	File transfer successful, transferred 7,074 bytes in 1 second
Status:	File transfer successful, transferred 6,897 bytes in 1 second
Status:	Retrieving directory listing of "/testing"...
Status:	Directory listing of "/testing" successful
The person who edited the files indicated they had used notepad --not sure if that's the culprit. But if I RDP directly into the server and simply copy/paste, the complete files are deposited.

User avatar
botg
Site Admin
Posts: 35509
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Incomplete files uploaded, but no errors

#2 Post by botg » 2016-07-15 16:52

Most likely a firewall or NAT router sitting between client and server is dropping connections prematurely.

Do you still experience this issue if using FTP over TLS? It protects against these issues going on unnoticed.

mtcg
500 Command not understood
Posts: 3
Joined: 2016-07-15 16:11
First name: Mt
Last name: cg

Re: Incomplete files uploaded, but no errors

#3 Post by mtcg » 2016-07-15 19:18

I tried tying an available certificate in IIS and set it to "allow SSL" connections.

Next, I logged back into FileZilla and selected "Use Explicit FTP over TLS if available."

When I do this, I'm prompted with a box about the server certificate and I hit ok.

The FileZilla dialogue is mostly the same, except for the added:

Code: Select all

Initializing TLS...
Status:	Verifying certificate...
Status:	TLS connection established.
Status:	Logged in
Status:	Retrieving directory listing...
Status:	Directory listing of "/" successful
Status:	Connection closed by server
The uploaded file sizes appear to still be less than the source files, but now when I open the contents of the file, the text is encoded as gibberish.

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

Re: Incomplete files uploaded, but no errors

#4 Post by boco » 2016-07-16 00:25

Are you transferring files as ASCII? Slight size-changes are normal for ASCII transfers as FTP will apply line-ending transformation if the server uses a different one. Binary files and files that are already in the target format will be corrupted, since there's no way to determine if line-ending conversion is required or not.

Switch to Binary and retry the transfers. Are the targets now the same?
No support requests over PM! You will NOT get any reply!!!
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org

mtcg
500 Command not understood
Posts: 3
Joined: 2016-07-15 16:11
First name: Mt
Last name: cg

Re: Incomplete files uploaded, but no errors

#5 Post by mtcg » 2016-07-18 13:15

boco wrote:Are you transferring files as ASCII? Slight size-changes are normal for ASCII transfers as FTP will apply line-ending transformation if the server uses a different one.
Thanks. It's not just the file size that was the issue: about 1/4 of the content within the file was missing. It was all basically HTML and the last person who had edited the file did so in Notepad.
boco wrote:Switch to Binary and retry the transfers. Are the targets now the same
Filezilla defaults to "auto" in terms of detecting the appropriate file transfer type. It was not explicitly set to ASCII. It's been a long time since I've had to explicitly designate the file type. Still, I switched to binary to see if that had any effect, and it did. Now the files match and the content is complete.

Which begs the question: why didn't Filezilla automatically detect the appropriate file type in this case? We've been using Filezilla to upload .ASPX files for years. And it would be very cumbersome to have to explicitly designate them as such, because only in a perfect world would one have solely that one file type in a mass upload.

So, the fix is that we have to explicitly designate "binary" for .ASPX files? That doesn't seem right.

I'm glad it worked, but I'm also concerned that we'll have to switch to a different FTP program if it can't auto-detect the appropriate transfer type, as it had done in past versions over the many years we've used the software.

User avatar
botg
Site Admin
Posts: 35509
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Incomplete files uploaded, but no errors

#6 Post by botg » 2016-07-18 15:52

Data type is solely detected based on file extension.

It's more than strange that your file has been truncated the way you described. Do you by chance have enabled "Allow resume of ASCII transfers" in FileZilla's settings? If enabled, corruption is essentially guaranteed if the server uses a different line-ending convention than the client.

Edude
500 Command not understood
Posts: 1
Joined: 2018-12-05 09:40

Uploaded xml file missing pieces, setting transfer type binary solved it.

#7 Post by Edude » 2018-12-05 10:11

Hi,
Thanks for posting this.
I noticed Uploaded text/xml files missing pieces.
I did not expect setting transfer type to binary would help, since the files were ASCII.
After finding and reading this topic I got the impression that setting transfer type binary could solve it, and it did.
I conclude the missing bytes are related to the difference in expectations for ASCII file line endings at the client, unix/linux (LF), and at the server DOS (CR,LF).
Regards.

Post Reply