Files mixed up on download

[mkoops]

When downloading the complete content of one of my
websites (so multiple dirs and files selected at once)
I discovered that Filezilla is mixing up the files: It
is storing file content of certain files with the
names of other files. It happens both for html files
as for images. I noticed this behavior when
downloading the website over 4 parallel connections.

Limiting the number of connections to 1 (disabling the
option to use multiple connections for file transfer)
did prevent this error to happen.

I was able to repeat this error multiple times (each
run affecting different files of the set) and could
reproduce the issue against different FTP servers (of
different providers)

issue noticed with client versions 2.2.18 and 2.2.22

[Tim Kosse]

This is almost always caused by a bug in Linksys routers.

Please reopen if you do not have a Linksys router.

[mkoops]

Reopened as requested:
I am not behind a Linksys router, but an Asus WL500g
router. Maybe this thing is showing same problem as the
Linksys routers, I don't know. I guess that both types of
routers are running quite similar linux distros, isn't it?

I must say that I am surprised to hear that a router can
pottentially mix up files. Never thought that a router
could impact to that level, but it is good to know for
future troubleshooting.

Anyway thanks,
Mark

[doomwookie]

I'm having the same problem both with downloads and uploads
to my sites with client 2.2.19a. I've had it happen behind
a dlink DI-624S, a Linksys W54G, and through a naked DSL
connection. It does this with it set to 2 downloading or
uploading connections. I have not tried it with more. It
is maddening enough with images getting swapped on website
uploads. Turning off multiple connections seems to solve
the problem.

[mike503]

YES! This is my #1 pet peeve! I keep downloading newer
versions hoping this is fixed, but it is not fixed yet.

A lot of time I will queue up directories with lots of
files; it seems that small files (47 bytes for example)
get "mixed up" and will wind up taking on the attributes of
a larger file next to it in the queue (what should be 47
bytes can wind up being 100 megabytes or more...)

If FZ can fix this bug and improve queue management more
(there's some other oddities, like the progress bar
sometimes does not display) I would contribute to show my
support, as it meets my needs and I find it easier to use
and cleaner than any other client.

Basically just stress test it on your own and see if you
can reproduce it. I can't really give any specifics, since
it is sporadic, but it seems other people are suffering
from it as well, so it must be something easy to reproduce
if you put in the time. Thanks.

[mike503]

okay I just read that last reply - what do you suggest here?

Is there a setting on the routers to fix this?

I notice people using other routers than linksys have
posted, so i know I'm not alone at least. I do have a
Linksys...

Could it be as simple as forcing PORT or PASV?

Is it an issue of multiple transfers from the same host
(but different hosts are okay?)

Is it an issue of multiple transfers inside of the same FZ
client (and launching another client using the same host
would be okay?)

Would using a machine to do NAT/firewall other than a
Linksys or D-Link (or who knows what other brand?) router
also fix this? Is it something as simple as changing the
packet filtering/inspection/etc?

[Tim Kosse]

I've reviewed the code multiple times and did transfers of
huge amounts of files of all sizes, each using plain FTP,
SSL, and MODE Z+SSL. Results were as expected, no filename
mixups.

Regarding router configuration: All packet inspection, DMZ,
"game mode", transparent port forwarding, stateful firewall
and similar things should be disabled, they just do more
harm than good.

What I know for sure is that this problem is not caused by
FileZilla.

[mike503]

I hate to keep harping on this, but why do other FTP
clients work if it's something wrong with the router?

I don't understand how the router is at fault; is it how FZ
reuses the same sockets/connections and that's where it's
getting confused, perhaps? I see it pretty cut and dry: a
file needs downloaded, so it should be able to have it's
own dedicated stream, no matter what file type or size or
connection it's on... perhaps you could add an option
for "unique connections for each file" (for some "broken"
routers) - which will still allow for multiple transfers
but will cleanly disconnect on every file being completed,
and reconnect a brand new connection instance for each new
file? that MUST be able to work then...

[Tim Kosse]

FileZilla does not reuse connection, after each transfer the
transfer connection gets completely closed. I see no way how
FileZilla can cause files to be mixed up.

[mike503]

is there some superdebug mode or something i can turn on
that will show all the details and which thread(s), ports,
etc, etc. are being used? perhaps that could help?

other people are experiencing this, as stated, and other
ftp clients don't suffer from it, so there is something
different about FZ. it probably runs better in general
except these specific conditions (which are quite common,
not working behind SOHO routers is a huge caveat)

i'm willing to help wherever i can. if i knew C++ or VC++
whatever it is written in, i'd examine the code and throw
in my own debugging/etc. but unfortunately i can't.

[Tim Kosse]

Try this: Enable "Trace messages from the FTP engine" on the
debug page in the settings dialog and enable logging on the
message log page.
The repeat these steps:

• Start FileZilla
• Transfer some files
• Check transferred files for validity
• If everyone looks ok, close FileZilla and delete the

logfile. Start from scratch

• On failure post the entire log and tell which files got

mixed up

[mike503]

Tim,

I was able to reproduce this with the logging on as you
asked. I have sent you the log to tim.kosseATfilezilla-
project.org.

Let me know if you need any more info, or a better email.

• mike@…

[Tim Kosse]

Thanks. After deleting most of the lines, but leaving the
relative order intact, the log shows this:

Response: 227 Entering Passive Mode (xxx,xxx,xxx,xxx,128,151).
Response: 227 Entering Passive Mode (xxx,xxx,xxx,xxx,128,151).
Command: RETR file1-backup.tar.gz
Command: RETR fil2-backup.tar.gz

For two PASV commands, the server sends the same reply,
awaiting the connection on the same port. Both replies get
received before sending the commands to get the files.

So this is clearly a problem with the server.

[Tim Kosse]

Another thing, please update the server to version 1.3.0,
version 1.2.10 is almost two years old.

[mike503]

okay i'm noticing this is a recurring issue with a lot of
folks. uploads and downloads.

can't there be some FAQ about this, or -anything- be done
other than "get a different router" ?

seems odd that my suggestion for creating a completely
fresh login for each file wouldn't fix it, if it's because
of the server replying with the same port. wouldn't fresh
connections fix it no problem?

could forcing it to be PORT vs. PASV help?

it would be nice to figure out a working combination.
linksys routers like mine are probably the most popular
routers out there because of the firmware options. someone
should fix it in the linksys firmware, figure out what the
issue is on the server side, or figure out some way the
client can adjust itself accordingly.

as far as the ftp daemon... i'll try to upgrade it
manually, but it's paired with the control panel stuff on
the server :) i don't know if it will fix anything but i'm
willing to try.