FileZilla Forums

This has been bugging me for awhile in FileZilla. The default queue behavior when adding a directory is to add each directory's contents in reverse alphabetical order. This strikes me as very non-intuitive. I can't remember the last time I wanted to upload or download a directory in reverse alphabetical order. I can't count how often I'd like to download in forward alphabetical order.

In my work I often use the program to download a series of documents, and I need to start work on them in consecutive order. Currently, I queue the files, then change the priority on the files I want first in order to keep from getting them last. There's currently no way to sort the list en-masse short of exporting the queue to XML, sorting it, and importing it again, which is even less intuitive. Short of redesigning the queue to be more flexible and respecting on-the-fly field sorting, would it be possible for FileZilla to use FIFO instead of FILO when adding files to the queue? It seems far more intuitive, to me.

FileZilla has never made any guarantees regarding queue sort order for performance reasons.

While filezilla is still arguably the best graphical ftp client out there today, I still find this bugs me. Most of my downloads are of directories with file listings from 01-20 for example. The files are sometimes large and take a while to download and I will always want 01 to be available first. Going through a set of 20 files and setting priorities cannot work as there are not enough priority levels. There does not seem to be an easy workaround for this only to let the files download in the reverse order.

Surely there must be a solution for this. It seems the sane way of doing things. I cannot understand why this is rejected each time it is requested by your user base.

There is definitely user demand for this, these are just a few I found with a quick search:
http://forum.filezilla-project.org/view ... ilit=queue
http://trac.filezilla-project.org/ticket/1318
http://trac.filezilla-project.org/ticket/2860
http://trac.filezilla-project.org/ticket/4766

Hi,

I am working on the feature enhancement of sorting the queue by any column.

Thanks,
Chaitanya.

I would like this option too, the idea is simple. Just put a priority in the form of numbers, that is 1,2,3,etc where the increasing number means the LOWEST priority. The kink here, though, is if you have 1000 files it's gonna be a hassle.

Can anyone please please tell me if there is any feature in the software that has a NO IP capability where any static IP can be set in your device and it will still pop up with the captive portal page to sign in to the network?

Thanks, DR01

There's no No-IP (dynamic DNS) feature in FileZilla. It's not even possible, as the external IP changes in the router.
Also, there's no portal page for FTP. Everything you may see is generated by your client.

Thanks Chaitanya - it would be great to be able to sort the queue (and thereby the processing order).

I sometimes have to upload a huge number of files, and would like to save the largest files for last. At the moment, the way to achieve this is not quick and easy.

Feature Request +1 from me too!

Actually I just realised, Chaitanya, something else that would be great too.

Often when I'm doing development on a site, I have a local copy on my pc. I sometimes use 'Replace in files' to replace a particular piece of code across the entire project.
If there was an additional column 'modified date', I could add the entire project to the queue, sort by modified date, and keep only items modified in the last hour.

Othertimes I only want to upload/download the code files.
If there was an additional column in the queue, 'File Extension', I could add the entire project to the queue, sort by file extension, and delete all the (usually larger) image files from the queue.

Would this help anyone else?

Just filter your project before adding it to the queue.

Menu View - Filename filters

cchaitanya wrote:Hi,

I am working on the feature enhancement of sorting the queue by any column.

Thanks,
Chaitanya.

So, this is still an issue as of 1/5/14 with version 3.7.3, I was really hoping that this would have been resolved by now.
I find it so annoying to have to try to continually adjust the priority of dozens of files to try and get them in a usable order that I've considered switching to another FTP client.

This has been bugging me since the first time I've been using FileZilla. If you want to download something that has an order, and start using the FIRST file, it gets downloaded LAST unless you modify the priorities file by file.

It is still an issue in 2016.

Fixing this should be a few minutes of time, and it's bugging a lot of people.

Fixing this should be a few minutes of time, and it's bugging a lot of people.

Replace minutes with days then it fits. The transfer queue is a very complex beast.

I don't want to start yet another topic on this, clearly this has been discussed at some length before.
I do however want to highlight that there is not just this one issue that people "would like to have", but that there are in fact *several* issues on top of that one, all to do with with queue handling in general, and all rather inconvenient for the user (to varying degrees). So maybe dev will reconsider after all - *fingers crossed*


1) the above mentioned complete unavailability of any *simple* way of sorting the queue after the fact.
[No, setting priorities by painstakingly clicking each item is not simple (enough)]

2) the fact that what the user sees as "the queue" is in fact TWO queues: One for items added by using the "add files to queue" menu item, and another one, of higher priority for any items added with the "download" menu item. Not only is the user not informed of this in any way, there is also no way to "fix" it after the fact (besides deleting+redoing the queue entirely).

3) the fact that adding entire directories sometimes adds the items in those directories in an unintended order (I've not re-checked this particular issue before making this post, and unfortunately I don't recall what exact order these items then end up getting added in, I just recall there was something off about it, i.e. it was different than the file sorting order currently selected in the source view).

4) the unavailability of at least a rough progress bar for the entire queue

5) the sometimes odd behaviour of the per-file progress bars in the queue: specifically, my max dl speed is 1.7 MB/s, but for some reason (presumably to do with CPU usage?) when I scroll or alt+tab I often see a much faster dl speed being displayed (e.g. some 2.5 MB/s or whatever)

the fact that what the user sees as "the queue" is in fact TWO queues: One for items added by using the "add files to queue" menu item, and another one, of higher priority for any items added with the "download" menu item. [...] there is also no way to "fix" it after the fact (besides deleting+redoing the queue entirely).

There is a way: Stopping and restarting the queue instantly transforms all immediate transfers to queued transfers.

4) the unavailability of at least a rough progress bar for the entire queue

Remember the file copy dialog from Windows 95 and it's time estimate? For any non-trivial queue content the progress bar would resemble it.

Consider one large file of 1GB file and a thousand of small files a few bytes in size. What is the overall progress if the large file has already transferred and the small files still remain? It can be 0.01% or 99.9% depending on complex factors such as latency, throughput, down to things like how many different directories are these files in?

On top of it the queue isn't fixed, it can be modified at any point while already being processed.

the sometimes odd behaviour of the per-file progress bars in the queue: specifically, my max dl speed is 1.7 MB/s, but for some reason (presumably to do with CPU usage?) when I scroll or alt+tab I often see a much faster dl speed being displayed (e.g. some 2.5 MB/s or whatever)

Buffering, congestion and unsteady packet delivery can cause this and related symptoms. Unfortunately this cannot be avoided.