Opened 13 years ago
Last modified 12 years ago
#7820 new Bug report
Pointer collision in commandqueue between enqueue and dequeue
| Reported by: | amma | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | FileZilla Client |
| Keywords: | commandqueue, workaround, pointer, collision | Cc: | xaminmo@… |
| Component version: | Operating system type: | Windows | |
| Operating system version: |
Description
Recreate the bug:
1- Add couple of files to the queue.
2- Make the simultaneous transfers less than the queued ones and start the transfer.
3- Add another files to the queue.
After finishing the download that already started while adding the new files the queue will start download the latest added files instead the queued ones before.
Change History (1)
comment:1 by , 12 years ago
| Cc: | added |
|---|---|
| Keywords: | commandqueue workaround pointer collision added |
| Priority: | critical → low |
| Summary: | Adding new files to the current transfer queue will take the priority → Pointer collision in commandqueue between enqueue and dequeue |
Note:
See TracTickets
for help on using tickets.
I can confirm this issue occurs. This is unique to the Fz3 command queue.
The likely cause would be a shared pointer for enqueuing and dequeuing to/from the command queue.
There are two workarounds:
If you uncheck "Process Queue" then recheck it, it starts again from the beginning.
Also, when the queue processor gets to the end of the queue, it starts again from the top, looking for highest priority. As such, if the existing items are higher priority than default, then they will continue to process prior to the new additions.
This has workarounds, so this cannot be critical.
Order of operations on a batch transfer of a manual process should be considered low priority, because it's user preference, only. No faults or data issues are at play.
Changing priority to "low"