Opened 19 years ago
Last modified 18 years ago
#502 closed Bug report
Last directory listing size / queued files size mix-up
|Reported by:||anonymous||Owned by:|
|Component version:||Operating system type:|
|Operating system version:|
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
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
Remote sys: VAX
Filezilla sys: NT4
Change History (2)
comment:1 by , 19 years ago
comment:2 by , 18 years ago
This bug report has been closed due to inactivity and has possibly
already been solved.
You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).
Logged In: NO
Correction (may not be a bug at all): It is the size of the listing of the file's own directory that is shown.
This is because before download of each file, the commands TYPE A; LIST are made. Still, I use 'directory
caching' which either does not work for Q'd files, or does not work for VAX remote server.
Filezilla version is 2.2.1b.