Custom Query (8170 matches)

When queuing files from a (remote) directory tree, the directory listing size (as shown by trf status during directory listing download) for the last scanned directory (usually the topmost one as it scans bottom-up, last-to-first) will be used as the initial/minimum trf size of subsequent file transfers, often for all queued files. With initial/minimum trf size I mean what is downloaded (according to status row below file in queue list window) before the graphical progress bar shows up - and at that point the transfer quickly completes (for large files rather speed increases considarably).

The result is that the file transfers for many small files take way too long time, e.g. a listing size may be 30KB, and the directory containing lots of small 1-10KB files, in case of which transfer time takes 10 times too long. Important: the stored files' sizes seem to get correct!

I have changed most options with no difference. I don't yet know if this problem only occurs in the present configuration: Remote sys: VAX Filezilla sys: NT4

Cheers! /Vayenn

cvs trunk (pulled within past hour)

Connect to remote site (upload.sf.net), via connection manager, using default mode.

It connects and executes ls command, and hangs (because it isn't using passive mode, I think).

Open up connection manager, alter it to use passive mode for this site, and hit connect button. Answer Yes to prompt for break current connection.

I get an ASSERT failure (UNICODE debug build) in source\MainThread.cpp, line 178, which is inside of CMainThread::OnThreadMessage.

lines 177-178:

case FZ_COMMAND_CONNECT:

ASSERT(IsConnected());

I speculate that the problem is that it was still trying to break the current connection. This doesn't reproduce if I do the same test with passive mode the whole time, but also it doesn't hang in that case.

When I rename a file in a remote FTP folder using a filename that already exists there, the remote directory listing (without refreshing) will then show two files with the same filename (see screenshot #1).

If I then delete one of the listed files (and don't refresh the remote directory listing), a blank file will appear at the top of the remote directory listing (before the parent folder link) that has only the Windows unknown file type icon, a random value in the filesize field, and "???" in the date field (see screenshot #2).

I attached a log.

This server doesn't send a 550 file exists error when I rename a remote file with an existing filename, but I think that FileZilla can be fixed slightly to accomodate this problem somehow.