Please check that the correct folders are selected for synchronization. My mounted source drive appeared empty due to the mysterious SMB networking bug, and FFS's sync therefore deleted the entire synced drive's contents (with a handful of errors that left a handful of files - 6493 items deleted, 13 missed).Ġ3:00:10 Warning:Ĝannot set directory locks for the following folders:Ĭannot write file "/Volumes/Media/sync.ffs_lock".Ġ3:02:12 Warning: The following folders are significantly different. So wanted to follow up here, bad news - exactly what I was afraid of finally happened. But the next time I do see it, I'll try running a compare and sync manually (so I'd catch an error) to see what happens, and report back here in case there's anything that could help you. I've only noticed the "volume appears empty" bug a handful of times over the past few months, so it's not something I can reliably test. I didn't know FFS had a 50% change warning, so that's good to know - is that documented anywhere? A quick Google search seems to reveal there used to be a "WarnSignificantDifference" set to 50% by default in GlobalSettings.xml, but current documentation doesn't show anything.īut I *do* check Ignore Errors on my nightly batch jobs, because they frequently run into small errors from random network timeouts or similar on a single file operation that would prevent the rest of the sync from happening - so now it seems like maybe I should be worried? "ls" behaves normally except lists nothing.
In both Finder and Terminal, the folder appears like a regular empty folder as far as I can tell, e.g. Thanks as always for the amazing amazing tool! to be able to set a sync to abort if it would result in more than 50% of files by count or size being deleted from the destination.) (I also wonder if it wouldn't be helpful to have some kind of explicit protection against massive deletion? E.g. So it might be helpful to readers just to make explicit that instead of "lock files" generally, there are 2 lock files specifically, both on source and destination?Īnd second, if my understanding is correct, then it might also be helpful to explain a second use case of ensuring that the source volume is actually functioning, in case network errors erroneously make it appear empty, then this protects against that.
The documentation seems to suggest it by referring to "lock files" in the plural, but it's not clear why a lock *would* be needed on a source, as opposed to just a destination. So I wanted to double-check that this is actually what is happening, and if so, might suggest some additional clarification in the description of "LockDirectoriesDuringSync" at ?įirst, it's not entirely clear from documentation that lock files are placed on the *source* directory. Then I realized it must be the sync.ffs_lock file - that FFS must attempt to create it on the "empty" source, but because the SMB interface is failing somehow, the file can't be created and FFS aborts. I suddenly worried - what if this happened nightly, that FFS saw the source as empty, and thus deleted everything in the destination? But this has never actually happened, so I wondered if something was protecting against it.
Occasionally, for mysterious OS/network reasons that have nothing to do with FFS, the source volume is mounted but appears entirely empty, and I need to variously reboot my computer and router to get its contents to appear again. I use FFS (on a Mac) to sync one external hard drive to another nightly, both accessed as mounted SMB volumes over a network.
0 kommentar(er)
