incorrect 'download' log message in status/transfer window

Build 3817

'download:' message incorrectly added to status and transfer logs under circumstances where it actually fails. This was encountered after launching multiple sessions to finish up a queue of files quickly. FER's in this case are set to resume (download+smaller), and the failure of course is because another session is already transferring the file.

[08:34:15] [L] Cannot open file D:\backup\ibdata1
[08:34:15] [L] The process cannot access the file because it is being used by another process.
[08:34:15] Download: ibdata1 0 bytes in 0.00 seconds (0.0 KB/s)

Thank you for your bug report.

There is clearly a problem and I will investigate the issue.

Just to note that the queue item is correctly handled, being marked as failed etc. The issue only started recently.

It looks like a high level change has revealed a low level defect.

The high level code was changed so that an exception did not necessarily mean that there was a transfer error, it could be an out of memory error, or something else.

The low level code neglected to set the transfer error flag before throwing the error.

This issue should now be resolved in FlashFXP v5.1 build 3818

This issue that you reported got me thinking and there is in fact a secondary issue here that was completely overlooked by both of us.

If you open multiple instances of FlashFXP to perform a parallel download of the same same content then FlashFXP should be able to handle this without any issues.

[08:34:15] [L] Cannot open file D:\backup\ibdata1
[08:34:15] [L] The process cannot access the file because it is being used by another process.

Even though you're using multiple instances of FlashFXP this condition can be avoided.

I've updated the code to create a unique Mutex based on the target path+name just before the file transfer rules are evaluated, this Mutex is then released when the file handle is closed or if the file is skipped.

If a secondary copy of FlashFXP attempts to download the same target then attempting to create the Mutex will fail and we can safely skip the file knowing that another instance is in the process of transferring it.

I also found another issue when performing parallel downloads. If multiple instances attempt to create the same local target folder at the same time then it fails. The code neglected to check the reason for failure, in this case the folder already exists.

I will be including these two changes in my next update.

Fantastic. These changes should also minimize left over failed items in the queue caused by this particular scenario, which is nice as it means any failed entries can be looked into knowing they are not just left over from parallel write attempts.