3021 Client Corrupting Transfers

[drfoo]

Brand new Win2K install with current updates. Installed FileZilla 3021 to copy some programs and such from another machine on the LAN. Zipfiles seem to go just dandy, but I've discovered numerous .exe and .jpg files that consistently copy incorrectly with no reports of errors. The copy is invariably smaller than the original, but I've determined that the files are NOT simply truncated as I thought initially.

I installed FZ 2232 on the same machine and it transfers the same files perfectly. The server in question is FZ Server 0.9.18 beta, but I don't really think that's an issue because of the following.

I installed FZ 3021 to another machine and attempted to transfer one of the problem files from a Linux machine running vsftpd and ended up with an identically corrupted file (I did a binary compare with one from the other machine).

I'm attaching a jpeg that has this problem.

MD5 of good file: 05872a9ed5da1fe69161a0469e0213ab *bigball.jpg (106228 bytes)
MD5 of bad copy: 2655392d8646aeefd912ff9db8ef0b62 *bigball.jpg (40692 bytes)

[drfoo]

JPEG that FZ 3021 hates

[Alexander Schuch]

Can you please also attach the corrupted file, if possible? Also, please make sure you use binary transfer mode (though, the size makes me believe something else went wrong).

Also, can you try to upload that file to some remote FTP server to rule out that your FTP server/OS/computer does weird things?

[drfoo]

Corrupted bigball.jpg

[drfoo]

The server side doesn't seem to be an issue. As I indicated, I'd already seen the problem with two different server machines running different OS's and FTP daemons. I've tried further permutations now with the following additional info:

The corrupt file is an exact tail of the original, missing the first 64K. I also checked a slightly larger .exe file that failed, it is also an exact tail missing the first 128K. Are you writing things in 64K chunks by chance?

It works FINE over the actual Internet every way I've tried it so far, even on machines that fail locally. So the speed of the connection seems to be a factor. I've got another Windows box here that transfers okay in identical conditions (same servers, same LAN, same exact switches even). That machine happens to be the fastest (C2D, i965 chipset, Realtek GBit NIC). The failing boxes have almost nothing in common, one is a P4 Northwood 2600, i850 chipset, Realtek GBit NIC, the other is an AthlonXP, SiS chipset, SiS 10/100 NIC.

I originally thought that a machine that failed would ALWAYS fail on a given file, but this is not the case. However, it fails with exactly the same result every time it does fail (at least so far after dozens of tests).

I'm attaching the corrupted JPEG as requested.
File Added: bigball.bad

[Tim Kosse]

Are you using any firewall or virus scanner software?

Please attach a log of a failed transfer with debug level set to 4.

[drfoo]

Transfer log of both success and failure

[drfoo]

No firewall software on either box and no hardware firewalls or even routers between them and the local servers. The AMD machine runs Symantec SAV9, but I disabled "auto-protect" and even stopped all Symantec services (and anything else I could think of) just to make sure. The Intel box runs AVG but I never run the on-access scanner. Again, though, I killed the whole program just in case. No change. I'm actually 99 percent sure I discovered this before I even installed SAV on the AMD box. If you really think that could be an issue, though, I'm willing to do a fresh install of Win2K on one of the machines.

I've attached a log from the AMD machine where the first transfer actually worked, but the second attempt gave me the corrupt file. As I indicated before, the program always reports success. The failure is immediately apparent though since the auto-refresh of the local file list instantly shows the smaller file size.
File Added: fzlog.txt

[Tim Kosse]

According to the log you're using an outdated FileZilla Server version. Please update.

[drfoo]

Log of failed transfer from Linux server

[drfoo]

Somehow I *knew* you'd focus on that. It's not the problem. If you read back, you'll see I get exactly the same result with completely up to date vsftpd servers on Linux machines.

Unfortunately, I had to deliver the AMD box today, so I don't have access to it anymore.

I'm attaching a log for a transfer of the same file from a vsftpd server.
File Added: fzlog2.txt

[Tim Kosse]

Are you writing things in 64K chunks by chance?

Yes.

I'm willing to do a fresh install of Win2K on one of the machines.

Didn't you say in your original posting that you were using a fresh install? Please try a fresh install to rule out any third-party software corrupting the transfers.

I just did another code audit and could not spot any problems. I'd say that there's something on your systems or network components which causes this.

[drfoo]

Yes, the AMD was a clean install, but that's a relative term. I indicated I couldn't be 100 percent sure I didn't have the AV software installed when the problem first showed up. So...

Fourth machine, Celeron 2.4Ghz, i865PE chipset, Marvel Yukon Gbit NIC.

1) Install Win2K w/SP4 - no updates, drivers, or anything else.
2) Install WinZip.
3) Unpack and install NIC drivers.
4) Install FZ 3021.

Download of the jpeg file failed in exactly the same way on second attempt.

C'mon, guys, it aint my boxes! They all work just fine. One of these is in fact my main machine which runs 24/7/365. It's possibly the single most stable machine I've ever worked with (and I'm in the biz, and have been since 1978, so that's saying something).

Even if there WERE a problem with my network (which oddly enough doesn't seem to effect ANY other programs), this would still be a bug. I don't see any other way to explain the attached screen-shot. The program is clearly aware (or should be) that the file is undersized, yet it insists the transfer was successful. That's a bug.

My gut says this behavior will repeat given the following conditions:

Win2K
Fast network
Relatively slow CPU or a busy machine

The filetype may have something to do with it, but that makes no sense to me since the program at least indicates it's using binary mode. I may do some more tests with other files when I get time. As I've indicated in the past, zipfiles have so far always transferred okay. That just seems strange to me.
File Added: fzbug.png

[Tim Kosse]

Try taking one of those boxes back home and plug them into a different network.

I'm certain that this is a problem with your network and not with FileZilla. Otherwise this wouldn't be the only bug report about this with hundreds of thousands of users of FileZilla.

[sf-robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).