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.

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?

### BEGIN SIGNATURE BLOCK ###No support requests per PM! You will NOT get any reply!!!
FTP connection problems? Do yourself a favor and read Network Configuration.All FileZilla products fully support IPv6.http://worldipv6launch.org
### END SIGNATURE BLOCK ###

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.

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.

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.