Opened 4 years ago
Last modified 4 years ago
#12247 reopened Bug report
Priority and sorting not respected.
Reported by: | Wolfie | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | ||
Component version: | 3.49.1 | Operating system type: | Windows |
Operating system version: | Windows Server 2012 Datacenter |
Description
If a queue is in progress and I change priority or the sorting (local file, remote file, size), then those changes are ignored. In order for it to be respected, I have to stop the queue, sort or update priorities, then start again.
Another related issue, ignoring priority here (let's assume all set to the same priority), newer files added to the queue while it's in progress get selected next after a current file has finished, instead of going to the next one in line. (ie, not doing "first come, first served.")
The priority was said to be fixed based on #11932, but it appears it hasn't. The mention of the sorting is just an added "bonus" I have noticed.
I verified I am using the latest version (3.49.1) before starting this ticket.
Change History (5)
comment:1 by , 4 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 4 years ago
I'm not talking changing what is currently transferring, I'm talking about stop/start in order to get it to respect the order you want it to download the other files. Without doing that, it will continue with the original priorities, as though no change has been made, so instead of starting on the first file that is marked as highest, it will continue to the next file that might be marked as normal, for example.
To clarify, I'm talking about the next file it picks to transfer, not abandoning an existing transfer because the priority was changed. It's the same issue as the ticket I referred to.
comment:3 by , 4 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
comment:4 by , 4 years ago
I'm noticing a pattern. If a priority is change while a transfer is in progress, then after that file is done, it goes on to the next file it was going to do, then after that, it follows the new priority. So it looks like it's selecting the next file, then taking a 'refreshed' look at priorities so it knows which file to do next after it starts and finishes the current new file.
ex.
Files Adam, Bravo, Charlie, David, Edward, all initially with "Normal" priority.
It starts on Adam. While on Adam, change Edward to highest and Bravo to lowest. When Adam is finished, it starts on Bravo, then transfers Edward since Edward has the highest priority.
What it should do is, when it's finished with Adam, is to go to Edward, then Charlie, David, and finally Bravo.
Again, I'm not saying that it should abandon Adam and immediately switch to Edward when the priority is changed. The stop/sort/start is to get it to recognize the new priority settings so that it doesn't do the above described behavior. Even if I don't make any other changes than Bravo being set to lowest, stopping, sorting (or changing priority at that point), then starting would resume with Adam and then properly skip Bravo until after the other files are finished.
comment:5 by , 4 years ago
The issue appears to be fixed in 3.50.0, will toy with it some and report back if the issue still exists.
Since resume is not a guaranteed capability servers have to support, changing priorities never interrupts running transfers.