Build 3826.
In certain circumstances queued items are mistakenly skipped. This seems to be related to the unique mutex implementation added to resolve the issue reported here
https://oss.azurewebsites.net/forum/track...ker_bugid=1027.
To reproduce.
1. Queue a number of folders for download and start the transfer.
2. Stop the transfer part way through the files in one of the folders.
3. Cause the remote source files to be moved (to force a remote file not found error)
It should be noted that 3. happened independently of me/flashfxp while my system was in hibernation for several hours.
4. Resume transfer. - Files are then correctly marked as failed.
5. Stop the queue again.
6. Edit the source 'path' field for the items that were failed as a result of the file not found errors. - Pointing to the new correct location.
7. Reset the modified queue entries and start the transfer again.
What happens then is that all the items are skipped with 'file exists' (as they would be if already being handled by another session, but there are no other active sessions). This occurs without flashfxp attempting to do anything on the remote side (no cwd etc).
8. Stop the queue again once it has begun working on the next folder in the queue.
9. Manually navigate and re-queue the folder containing the incorrectly skipped files.
10. Move it to the top of the queue and start the transfer.
Same result, with files incorrectly skipped.
It seems that the unique mutex is never reset/removed when perhaps it should be at some point? Or at least check if the local file actually exists before triggering the skip rule?
To resolve it and be able to download the files the session had to be closed.