Mirroring an unreachable host deletes everything you have

Get help for specific problems
Posts: 2
Joined: 7 Aug 2020

TinySmith

Very simple scenario: if you have a one-way mirror job set up, where the source is a network filesystem and the destination is a local disk, and the source host is unreachable, if you execute the "sync", it deletes everything you have locally. This is terrible.

Suggestion: if the source path is a network share (begins with "\\"), check that the share is actually reachable. Or, if that is technically impossible, display a special urgent warning "It looks like the remote filesystem you are trying to mirror has nothing in it (or is simply unreachable via the network). Do you really want to delete everything from your destination?"

Perhaps if I actually try to do the mirror, as opposed to the "compare", it will warn me, but I don't think it should even get this far, displaying trashcan icons for everything. We cannot rely on the "major changes detected, please confirm", since some people turn that warning off.

Obligatory environmental info: Windows 7 64-bit, Intel Core I-9 processor, custom build.
Posts: 936
Joined: 8 May 2006

therube

have a one-way mirror job set up
<FolderPairs>
        <Pair>
            <Left>\\nas\PUB\mirror.TEST222</Left>
            <Right>C:\TMP\mirror.TEST2</Right>
        </Pair>
    </FolderPairs>
job set up
So this is a .ffs_batch?
and the source host is unreachable
What constitutes "unreachable"?
Is renaming the source (\\) directory sufficient (such that when the .ffs_batch file runs the named it looks for \\nas\PUB\mirror.TEST222 but you've renamed it to \\nas\PUB\mirror.NOT [in the .ffs_batch)?
if you execute the "sync"
Does running the .ffs_batch file constitute "execute the 'sync'"?

If I follow the above, I get a message that \\nas\PUB\mirror.NOT does not exist yet, that the source folder, \\nas\PUB\mirror.NOT is not found.

And with that, nothing is synced back to my C: drive, so C: is left unchanged.
User avatar
Posts: 3551
Joined: 11 Jun 2019

xCSxXenon

Mapped as a drive letter, it works. But, it should definitely determine that the location is unreachable just as it searches when set to a drive letter. I don't know if there is a way to integrate Window's network utilities
Posts: 936
Joined: 8 May 2006

therube

Posts: 2
Joined: 7 Aug 2020

TinySmith

Not bothering to reply to you, TheRube, since you just want to point up every possible ambiguity, naivete, or mistake in my posting instead of addressing the obvious issue which I made abundantly clear. Bye.
User avatar
Posts: 2250
Joined: 22 Aug 2012

Plerry

Likely, you chose to Ignore Errors when saving your *.ffs_batch configuration.
There are always risks involved in ignoring erros instead of showing errors
or cancelling the sync, and you have just experienced one such risk.

There is a however a simple solution to this problem:
Store the *.ffs_batch file in \\nas\PUB\mirror.TEST222 and run it from there.
Is \\nas\PUB\mirror.TEST222 not available or not accessable, then your sync simply will not run.

But I agree it would be better if (if possible) some protection would remain active in FFS, even when ignoring errors.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Very simple scenario: if you have a one-way mirror job set up, where the source is a network filesystem and the destination is a local disk, and the source host is unreachable, if you execute the "sync", it deletes everything you have locally. This is terrible. TinySmith, 07 Aug 2020, 16:43
This is not what will be happening. Instead, when you actually start the synchronization FFS will show an error message about missing source folder and skip the whole folder pair. Nothing will be deleted.

Perhaps if I actually try to do the mirror, as opposed to the "compare", it will warn me, but I don't think it should even get this far, displaying trashcan icons for everything. TinySmith, 07 Aug 2020, 16:43
Agreed, it looks scary. FFS doesn't just disable all items at this step, because this would make it impossible to have a non-existent *target* folder created automatically during sync. Maybe there is a way to handle both scenarios => ToDo
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Fixed in FreeFileSync 11.10: FFS now carefully distinguishes "not existing" from "error while trying to determine folder status".

First case:
1. if source folder missing: same error during sync as before.
2. if target folder missing, it will be created during sync.

Second case:
All items are visually disabled => crystal clear that nothing will be done. No leap of faith necessary anymore to rely on the error message *after* pressing sync. Bonus: sync statistics are now correct.

https://www.mediafire.com/file/tj6s04d54j0mwk2/FreeFileSync_11.10_%255BBeta%255D_Windows_Setup.exe