When using automatic retries, I had hoped that the delay option would simply delay the retry of the selected thread. It appears that ALL threads suspend (delay) while waiting for this timeout. I especially noticed it when more than one thread had an error/retry. I had set the delay for 20 seconds and I noticed that nothing was copying for over a minute.
Can someone please explain how best to use threads/ignore errors/automatic retires/delay, etc.?
I'm get TONS of errors writing(syncing) to a new NAS... and automatic retries is a lifesaver over copying files one at a time... however, 150GB is slated to take 6 DAYS at this rate.
Thoughts? (I've already tested the network, the drives, etc. - right now I'm focusing on the most efficient settings for FreeFileSync).
What does delay do in automatic retries?
- Posts: 17
- Joined: 27 Jul 2020
-
- Posts: 4056
- Joined: 11 Jun 2019
The best way to set the settings is whatever you decide is best. If you want less delays, reduce/disable delays
- Posts: 17
- Joined: 27 Jul 2020
So you have no idea what the delay is actually delaying? The retry, or the processing of all the threads? It appears to me, that when an 'Automatic retry' is displayed on the screen, the other threads are stuck - or at least the update to the display of Processed: does not update... idk.
I was hoping the delay time would allow other threads to process without the 'stuck' thread tying things up by restarting right away?
I was hoping the delay time would allow other threads to process without the 'stuck' thread tying things up by restarting right away?
- Posts: 17
- Joined: 27 Jul 2020
Plus, it also appears that the Processed: (xx.x GB) is the total attempted... NOT the total completed. I am copying 1.5GB files, it has completed 2 of 6 - the other 4 are stuck in thread retires... but the display is showing 16.0 GB Processed... which may well be attempts... but is definitely not successes.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
The delay directly affects the failing thread, and thereby blocks the main thread. This means the other threads finish their current operation until they want to begin their next task: doing so requires access to the main thread to notify status, so they're also blocked.
This behavior may arguably be better than only blocking the failing thread. Assuming the most likely error condition to be a temporary network issue (why else would you want set a delay!?), it's better for all threads to wait until conditions are (likely) better.
This behavior may arguably be better than only blocking the failing thread. Assuming the most likely error condition to be a temporary network issue (why else would you want set a delay!?), it's better for all threads to wait until conditions are (likely) better.
Yes, this is by design. It's not "attempted" however, but actual bytes transferred. If copying a 2 MB file fails while having copied 1 MB, the 1 MB still counts towards "processed".Plus, it also appears that the Processed: (xx.x GB) is the total attempted... NOT the total completed. whalehead99, 07 Jul 2024, 21:33
- Posts: 17
- Joined: 27 Jul 2020
Thanks, I appreciate the update on the threads & delay.
One the Processed... just seems odd to me, that in a file *SYNC* app, we wouldn't care about bytes transferred, but bytes *successfully* transferred. Same with the file count, if I tried to send a file 5 times, do I count it as 5 when it finally syncs... or even when it doesn't sync? No big deal, processed just doesn't provide me (the user) useful information.
Nice product. Thanks for the responses. Have a great day.
One the Processed... just seems odd to me, that in a file *SYNC* app, we wouldn't care about bytes transferred, but bytes *successfully* transferred. Same with the file count, if I tried to send a file 5 times, do I count it as 5 when it finally syncs... or even when it doesn't sync? No big deal, processed just doesn't provide me (the user) useful information.
Nice product. Thanks for the responses. Have a great day.
