queue gets self-deleted during lot of [R] Transfer Failed:

hi

using latest beta 3829 i experienced something which is perhaps little bit difficult to reproduce. just imagine you have queued a lots of files and suddenly source changes e.g. files/folders get deleted so if you start your queue later you get a lots of :

[17:54:45] [R] Transfer Failed:
[17:54:45] [R] Transfer Failed:
[17:54:45] [R] Transfer Failed:
[17:54:45] [R] Transfer Failed:
[17:54:45] [R] Transfer Failed:

like this and the items stay in queue, marked red...

i had this today and during the transfer where every file failed i just changed the destination local folder on hdd and "suddenly" the queue emptied by itself and all the failed files are again listed this time with this error :

[17:54:54] [R] Skip [File Exists]:
[17:54:54] [R] Skip [File Exists]:
[17:54:54] [R] Skip [File Exists]:
[17:54:54] [R] Skip [File Exists]:
[17:54:54] [R] Skip [File Exists]:
[17:54:54] [R] Skip [File Exists]:

and as summary :

[17:54:54] Transferred 0 Files (0 bytes) in 30 seconds (0,0 KB/s)
Skipped 263 Files and 0 Folders

so we had those 30secs where all the 263 files i had in old queue just run by run and "failed" and i "just" changed the destination folder which should cause no interuption and suddenly without my interaction the "skip file exists" stuff comes and queue is deleted, queue file aswell

sucks imho this problem , so you have to "re-queue" anyways cause source is not avail anymore cause someone in my company moved the files to some subfolder thats why my queue failed.

anyways. this is a bug and should be fixed..

thanks!

Thank you soooo much for this bug report.

I've been trying to track down a problem that was discovered a couple weeks ago but I was not able reproduce it, I've spent many days now trying to find the true source of the problem.

Just before the transfer starts a mutex is created to prevent multiple instances of FlashFXP from concurrently downloading the same file, the handle of this mutex is stored in a variable, when this specific type of transfer failure occurs an exception is raised to exit the procedure, now just before the procedure is exited a cleanup is called to make sure the mutex handle is closed but because the file wasn't actually transferred some variables used for evaluation aren't set correctly and as a result the handle isn't closed, instead its added to a list to close later on.

Now when you attempt to re-try the files because this mutex exists the files are skipped.

Turns out this you bug you found is the culprit causing all sorts of mischief because in some cases its trying to the close handle multiple times and if the handle was re-used for something else it can lead to all sorts of failures.

I am working on a fix and as soon as I have one I will post it on this bug report. I also plan on releasing beta update today to address it via LiveUpdate. (The current beta build 3832 does not fix this problem as I thought it did)

I have released v5.1 build 3833 that should resolve this problem along with the other problems associated with this issue.