Custom Query (8117 matches)

If I try to change password with server\change password reports that odl password is not correct. If I try chmod works fine. This is because Filezilla adds quote on begining and end of paasword phrase. Exp. chmod passold passnew - this is right, but filezilla sends to server chmod "passold" "passnew" - wrong. You have to sent without quotes. Then works.

When *.*.*.* is typed into the IP filters (any of them) to block all IP addresses (turn the server off effectively), the server sends a response when a connection attempt is made.

Currently it sends the welcome message.

This allows anyone sniffing for an FTP server to confirm there is indeed a server there. It should NOT send a response - ie. it should be in stealth mode.

The result is that the server may then suffer a Denial of Service attack on that port.

This causes a secondary error in that the FTP server tries to send the welcome message back to every connection attempt (which should not be allowed) and promptly kills the server.

Not only that but us poor sods who have to pay for our data usage (or have traffic limits) then promptly get a large bill.

Just testing out the 2.2.15 client along side the previous version. The setup is two laptops plugged directly into a 100mb/s switch into the server running filezilla server 0.9.10.

When I upload a directory with about 13000 files (700 folders - 390mb) in it the client hangs for about 30 seconds and 'not responding' appears in the title bar. (In case someone is wondering, I was moving a s/w application to another machine)

It then proceeds to list every file in the directory that is to be copied and all sub-directories in the 'remote site' window, which takes approx. another minute, then queues up every file in the process queue taking a further minute (if it takes too long the server times out the connection and it requires the operation to be restarted). It then copies all the files to the server as would be expected. It should not be auto-listing files in the remote window - this is both bad usability and costely in CPU cycles for no reason.

If I delete the directory on the server (via the client remote site window), it then lists out the contents of all the subdirectories in the remote window, again taking ages, then queues them up, then issues a DEL command for every single file - the whole process took 15 mins where all that was needed was a DEL command to be issued on the root directory (the one I selected) and the OS should have done the rest.

When I use the previous version, it does not list out all the files in the remote site window before adding them to the process queue. It also takes less time to do the transfer (perhaps there is a config change or something)

So there are two problems. First, it takes a huge amount of time simply to copy a directory full of files (locking up filezilla), and second why are actions not offloaded to the OS (such as delete the directory, rather than every file individually).

As a comparison, zipping the directory in winzip took 2 mins, Ftp'ng the resulting 190mb file to the server took 1 min and deleting it took half a sec. There is enough information in the windows file system to tell you it was a large transfer and compression is needed - why not use it.

Also, if configurations changes are being made between versions, please list them in a readme as well as bugfixes etc.