Opened 10 years ago

Closed 10 years ago

#5237 closed Bug report (rejected)

Download problem, large file corrupt Fz-Client 3.3.2

Reported by: alessandro Owned by:
Priority: normal Component: FileZilla Client
Keywords: large file corrupt Cc:
Component version: Operating system type: Windows
Operating system version: Vista32 sp2

Description

I'm using last FZ-client 3.3.2.

When i try to download a large file more the 400Mb (.tar, .gz, .tgz, tar.gz)
from Linux RH server, i can download the file completely
with the same file size (binary or autodet. mode), but when i try to open the file result corrupted !!

  • there is no error during the transfer operation.
  • both of the machines win/Linux have 100Mb-FD lan speed.

S.O : Win Vista32 sp2

Regards
AleX

Attachments (1)

diff_bin.txt (1.0 KB ) - added by alessandro 10 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 by Tim Kosse, 10 years ago

Status: newmoreinfo

How exactly do the files differ? Use some binary diffing tool to show the differences.

comment:2 by alessandro, 10 years ago

Status: moreinfonew

Hmm..but, how can i see the difference if
one file is on "Linux machine" and the other
is on the "Windows machine".. :(

Can i try to import the "regular" file from linux,
using usb flash key !?

I will try as soon as possible .

Regards

  1. (italy)

by alessandro, 10 years ago

Attachment: diff_bin.txt added

comment:3 by alessandro, 10 years ago

I have checked both of files, have different "checksum" and lot of binary data
inside are not the same, look the attachement..

Both of files have the same size, but the file received by FileZilla FTP client
is corrupted.

I have cecked the files using "jojodiff07" sourceforge software !!

How can i solve this problem !?

Regards
ZaX

comment:4 by Tim Kosse, 10 years ago

Status: newmoreinfo

Unfortunately that diff is of no use without the context, which in this case would be the original file.

Do you by chance have a human-readable diff?

Essentially, I'd require hexdumps of the changed portions of both files.

Alternatively, you could make both files available (including the checksums) for me so that I could compare them myself.

comment:5 by alessandro, 10 years ago

Status: moreinfonew

I've try to made an Hexdump using Linux...but we are talking about
more than 600Mb for both of files. If you may tell me an easy way,
i will do ...for example where can i attach a large files like that !?

Regards
ZaX.

comment:6 by Tim Kosse, 10 years ago

Status: newmoreinfo

You can upload the files to 134.130.113.59, port 20202, explicit FTP over TLS, username "corruption", use the e-mail address associated with your account on this Trac as password.

comment:7 by alessandro, 10 years ago

Status: moreinfonew

Hi guys...before to send you the Hexdump, i have find an article about my problem
on microsoft support.

http://support.microsoft.com/default.aspx/kb/934376

What do you think ?!

I have updated Vista with last patch 'n service pack, but nothing is changed !!

Waitin for your opinion.

Regards
ZaX

comment:8 by Tim Kosse, 10 years ago

Status: newmoreinfo

From the MS site:

This problem occurs if the application is based on WinINet FTP functions.

FileZilla is high quality software and as such does not use that ugly WinInet stuff.

comment:9 by alessandro, 10 years ago

Status: moreinfonew

I'm trying to upload the large files into your FTP server using the "data"
that you have sent me, but i receive 'Connection Timeout' .

May check what happen !? ..

Regards
ZaX

comment:10 by Tim Kosse, 10 years ago

Status: newmoreinfo

The server has been up and running all day. Are you using the correct port and the FTP over explicit TLS protocol?

comment:11 by alessandro, 10 years ago

Status: moreinfonew

During the upload files about my problem...
after 1 hour, i receive this message from your FTP server :

"GnuTLS error -53: Error in the push function.
Errore: Tempo scaduto per la connessione
Errore: Trasferimento file fallito dopo aver trasferito 4.063.232 byte in 672 secondi" ..after that the connection has been close.

Let me kmow . :(
Regards
ZaX

comment:12 by Tim Kosse, 10 years ago

Status: newmoreinfo

Why did you delete the files again instead of simply resuming the transfer?

comment:13 by alessandro, 10 years ago

Status: moreinfonew

Cause i prefer listen you intead of give an half file ..
To transfer that file needs more than 1 hour,
but what means that error !?

GnuTLS error -53: Error in the push function

So, what you prefer !?
Try again to transfer the LARGE files or what else !?

Regards
ZaX

comment:14 by Tim Kosse, 10 years ago

Status: newmoreinfo

I want you to upload the files. If the transfer fails, resume the transfer. Do not delete the files.

comment:15 by alessandro, 10 years ago

Status: moreinfonew

I'm trying to upload the large files...
But i receive "ETIMEDOUT - Connection attempt timed out" often !!

I will re-try tomorrow morning .

Regards
ZaX (italy)

comment:16 by alessandro, 10 years ago

Hi guys...

I HAVE FINISHED NOW TO UPLOAD THE 2 LARGE FILES..NOW.

I'm waiting for your check about this problem !!

Have a nice work. :)

thank you in advance.

AleX (alias zax)

comment:17 by alessandro, 10 years ago

Hi Guys ..

do you have some news about my problem !?

have a nice day.

Regards
ZaX

comment:18 by Tim Kosse, 10 years ago

Resolution: rejected
Status: newclosed

The files are mostly identical, with the exception of some small parts where two blocks of data, 1448 bytes in size, are swapped.

If you add TCP and IP headers, that is about the size that fits into a single packet that gets transmitted over the network.

Since virtually all FTP products operate on larger buffers for performance reasons and leave the chunking into network sized blocks to the TCP stack, this suggests that there is something wrong with the network.

Unfortunately I cannot help you any further as analysing such complex network issues remotely is impossible.

As workaround please switch to an encrypted protocol such as FTP over TLS (FTPS) or the SSH File Transfer Protocol (SFTP), they are inherently protected against data corruption.

Note: See TracTickets for help on using tickets.