HandleError - need to retry

[somemirtexx]

Hello guys and thanks for the wonderful soft!

Is there a possibility to handle errors in a batch file with the retry. This
would be a great feature for a sync over bad/slow connections.

Thank you for your help in advance.

[Zenju]

Are you talking about a "retry" option when loading a FreeFileSync batch file
(*.ffs_batch) fails?

[somemirtexx]

Thanks for the reply.

No, I mean the Retry option during synchronization when done from
FreeFileSync. However there is no such option for RealTimeSync, although, I
guess, there should be one. And it should be "Retry for all errors", no pop-
ups.

[Zenju]

Are you using the most recent version of RealtimeSync? There shouldn't be any
popups when a directory is not existing (yet).

[somemirtexx]

Yup, I'm using the last version.
No man, it's not about "not existing" dir. It's about network outages during
the copy.

[Zenju]

What popup messages are you getting exactly?

[somemirtexx]

I don't get any. The batch job is configured to Ignore errors, whilst I need
to silently Retry for every error.

[Zenju]

There is a small misunderstanding: RealtimeSync does no synchronization,
FreeFileSync(=FFS) does. Former is technically (almost) completely decoupled
from FFS. So your feature request would be to add a automatic retry option for
FFS's batch processing.
But why would you need such an option in your scenario: Whenever there is a
network outtage, RealtimeSync will trigger a new synchronization as soon as
the network path becomes available again.

[somemirtexx]

Thanks! Yes, I do understand this...
This indeed would be a great option.

This is the part of the log:
"Windows Error Code 64: The specified network name is no longer available."
This happens due to the bad network connection.
FFS will write the tmp file on the destination and leave it there. I also
noticed once that it tried to write a temp sync.ffs_db and then also left it
there due to the above error.

It would be great to have a silent retry option.
BTW, I just tested FFS.
I ran a sync and switched network on-off generating "Windows Error Code 64".
Using Retry would not solve this, it would pop-up the error again in a minute.

[somemirtexx]

I rechecked, FFS doesn't work correctly on bad connection (though does
fantastic job on good connection or locally).
If you could add some robustness to the copy, it would be great (like in MS's
robocopy, it works great on bad connections).

[Zenju]

>doesn't work correctly on bad connection
What exactly is not working "correctly"?

[somemirtexx]

Well, it does it's job, but after the reconnection and pressing Retry, FFS
leaves ffs_tmp file in the destination.
Also, the retry doesn't work at all if the network failed during the Compare
phase.

[Zenju]

>FFS leaves ffs_tmp file in the destination
I'm not sure what could be done about this. The only thing the tool could do
would probably be an automatic cleanup. But this wouldn't be very transparent.

>doesn't work at all if the network failed during the Compare phase.
Unfortunately this is a technical restriction. If traversing fails due to a
network drop, retry is not possible, because the "search handle" is
invalidated. The button though is still on GUI for harmonization of error
handling.

[somemirtexx]

Well, in case of retry it can check <Filename>.ffs_tmp* and clean them up.

Zenju, is it possible that you will implement this retry (in batch) option
along with the cleanup in a nearest future?

[Zenju]

> in case of retry it can check <Filename>.ffs_tmp* and clean them up.
Sounds reasonable, I'll see about implementing for v3.7!

[somemirtexx]

Great, thanks!
When will it be released?

[somemirtexx]

Zenju, any ETA please?

[Zenju]

I release roughly about once per month, so v3.7. will be somewhere in that
range.

[somemirtexx]

Cool, 10nx

[somemirtexx]

Hello Zenju,

I checked the sources, wanted to see if I can commit this change by myself,
but =)
It'll take long to get into code.

Just to make things clear, my changes proposal is:
1. Automatic retry option for FFS's batch processing to overcome "Windows Error Code 64: The specified network name is no longer available."
2. Same silent retry for sync.ffs_db writing. Bad things happen when it fails to be written to a destination.
3. Handling of *.ffs_batch files for a failed syncs.

Does it look good? Can this be implemented?

Thanks!

[Zenju]

> Just to make things clear, my changes proposal is:
> 1. Automatic retry option for FFS's batch processing to overcome "Windows
Error Code 64
I see this functionality handled outside the tool rather than providing a
distinct setting for it. E.g. by using a batch file that checks the returncode
after a sync and restarts if it was not successful.
The basic design idea for FreeFileSync is to handle all common sync-scenarios
by providing specific settings within FFS. However usecases that are not
frequently required or are very special are not directly covered. Nevertheless
the aim is to provide some basic support even in these cases (e.g. by
returning error codes or allowing a silent batch mode synchronization,
RealtimeSync) so that they still can be fulfilled albeit somewhat less
convenient.

> 2. Same silent retry for sync.ffs_db writing. Bad things happen when it
fails to be written to a destination.
Actually this is not as critical as it might seem. The worst thing an outdated
db-file entails are possibly a few new conflicts, but at least there is no
loss of data.

> 3. Handling of *.ffs_batch files for a failed syncs.
Not sure what this means.

Regards, Zenju

[somemirtexx]

1. Yes, but that will leave ffs_tmp files...
3. Sorry, I meant ffs_tmp.

So, will something of this be implemented in 3.7?

[Zenju]

> So, will something of this be implemented in 3.7?
Currently I've implemented the logic that after synchronization it tries
(again) to remove all temporary files. This will solve your usecase of
occasional network drops and the user manually pressing "Retry". In this
specific scenario it can be assumed that the network drive is available at the
end, else "retry" would have failed until it is. Therefore all temp files most
likely will be deleted successfully.
Of course this is not working if the network drive still is not available at
the end. (For example if sync is aborted or errors are ignored)
In this case the handling above is not sufficient. Therefore I'm thinking
about a different solution: One option would be to silently delete all
*.ffs_tmp files, either during program start/comparison or some other time.
This is very implicit and seems risky. Therefore probably the best and most
transparent thing is to mark all *.ffs_tmp files for deletion during
comparison. This ensures these temp files will be reliably removed by the next
sync.
Trying to remove them after sync won't be needed anymore, after all let's not
forget that leaving behind temp files is an extraordinary situation and won't
occur as long as the target drive is available.

[somemirtexx]

Thanks, Zenju.
However Retry option is still not available for a batch jobs.

[Zenju]

Basically I see two solutions. The first would be a simple batch job that
restarts synchronization if something goes wrong. A delay could also be
included if necessary:

In a .cmd or .bat file:
-----------------------
restart:
"C:\Program Files\FreeFileSync\FreeFileSync.exe" "H:\Silent_Config.ffs_batch"
@if not errorlevel 0 (
goto restart
)

The second solution is to use RealtimeSync. If the connection to any drive is
lost, it waits and restarts synchronization as soon as all directories are
available again. This however only makes sense if a recurring synchronization
is needed.

[somemirtexx]

Ok, great, 10nx.

[somemirtexx]

'Tried to implement but this won't work. Looks like FFS won't return
errorlevel, for both .bat and RTS. Log:
Error: Error copying file:
Info: Generating database...
Warning: Synchronization completed with errors!
Stop (Total time: 00:07:19)

And after that sync won't reoccur.

[somemirtexx]

'forgot the error line:
Windows Error Code 64: The specified network name is no longer available.
Info: Generating database...
Warning: Synchronization completed with errors!
Stop (Total time: 00:07:19)

[Zenju]

> Looks like FFS won't return errorlevel
What is not working? Do you mean your bat file won't enter the "if"-part if an
error occured?
-> @if not errorlevel 0 (

[somemirtexx]

Exactly. Same as RTS won't retry sync.