Mirroring an unreachable host deletes everything you have

[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.

[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.

[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

[therube]

(Somewhat related, Slow to open when device offline.)

[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.

[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.

[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.

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.

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

[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