Client upload and download restart after 95-100% complete.

[dwtraleigh]

When connected to a client's ftp site(a fortune 100 company), I often can't successfully download or upload files. The process gets 95-100% complete and then puts up a pop-up 'target file already exists' when it tries to restart. If I choose 'Overwrite', the same thing happens again. Sometimes, usually with smaller files (< 10MB), filezilla works. The windows command line client always works. I used to use LeapFTP and it always worked. I'd like to move to FileZilla but 50% of the times I need an ftp client, it is for this site. What kind of traces can I get for you to help figure this out? Unfortunately, the site is restricted so I don't have a way to tell you how to recreate the problem yourself.

[Tim Kosse]

Problems like these are almost always caused by broken routers and/or firewalls.

FTP uses two connections, one control connection to submit commands and to receive replies as well as one data connection for the actual file transfers. During a transfer the control connection stays completely idle.

Now these broken firewalls and routers simply drop the control connection. The result is that the client never sees the "226 Transfer OK" response from the server. If that happens the transfer times out. FileZilla will then automatically try to resume. If that for whatever reason fails as well the file exists prompt will come up.

To solve these issues make sure that the server supports resume and that all routers and firewalls involved adhere to ​RFC 5382

[dwtraleigh]

Replying to codesquid:

Problems like these are almost always caused by broken routers and/or firewalls.

FTP uses two connections, one control connection to submit commands and to receive replies as well as one data connection for the actual file transfers. During a transfer the control connection stays completely idle.

Now these broken firewalls and routers simply drop the control connection. The result is that the client never sees the "226 Transfer OK" response from the server. If that happens the transfer times out. FileZilla will then automatically try to resume. If that for whatever reason fails as well the file exists prompt will come up.

To solve these issues make sure that the server supports resume and that all routers and firewalls involved adhere to ​RFC 5382

Thanks for the explanation. It sure does fit. Seems like a 2008 RFC is kind of expecting a lot for a network so vast. Is there some way to work around this? Why don't other programs have the same problem. Could filezilla somehow heartbeat the control connection to keep it up?

[Tim Kosse]

RFC 5382 just sums up what has already been written for decades in various other specifications.

Router and firewall vendors however do not care about specifications, all they care about is getting your money and thus only deliver barely working lowest quality junk.

FileZilla also uses TCP keep-alive, naturally some routers and firewalls ignore those. You need to properly configure your routers and firewalls and if needed, replace the faulty ones.

No idea why other clients may or may not exhibit this behavior, all I care about is that FileZilla operates according to the specifications. I'm not going to implement ugly workarounds.

[Slavon]

​http://smartmiltoys.com/kidkraft-dollhouse/