I've just started using FFS (v14.2). A strange thing that I've observed is that FFS apparently creates a lock file during synchronization, even though that particular directory root does not have a single file that needs synchronizing (as determined by a prior compare step).
Example:
In that particular example, I ran a Comparison action first (F5 key) and after that a Synchronization action (F9 key). FFS creates a lock file at M:\Photos (see text in popup), even though the two pairs using M:\Photos on the left side don't have a single file that is different (see Overview pane on the bottom right).
Does FFS rerun the Comparison step, when I run the Synchronization step? If it doesn't, then it should ideally only create lock files, if there are actually any changes to sync for that directory.
FFS doesn't re-run the compare, but it will lock every root location regardless of the presence of file changes. This would be a new feature request, but there's need to be a good reason for it
FFS locks the root locations when starting the Compare phase.
At that time FFS still needs to determine if any sync actions are required for any of its locations.
Only after the Compare phase, FFS could potentially (already) remove the lock-file for those locations not requiring any sync actions.
I suppose for simplicity the FFS author choose to always remove lock-files only after the actual sync has completed.
Note that you can not disable the use use of lock-files by setting the LockDirectoriesDuringSync flag to "false"). Make sure to read the risk when doing so.
I'd like to add a reason. I have folder A and I want to mirror it to folders B and C. Since they are both mirrors, A will not be changed. So in theory I could run both mirrors at the same time. But the way it's implemented now, I have to run one then the other. Probably the lock file should still be created but keep information about how the folder is being used. Then if another mirror is run it would see there is no conflict and it could proceed immediately.
> But the way it's implemented now, I have to run one then the other.
You can run both syncs at the same time, only not in separate FreeFileSync (FFS) instances.
You can define a sync that has two left-right folder pairs:
A => B
A => C
You can define that as a dedicated sync configuration, or in the FFS GUI select the two names (shift-click) of A-to-B and A-to-C sync configurations.
Note that you will only get a (correct) warning that some locations (in casu location A) are part of multiple folder pairs, which may give rise to problems or unexpected sync results. However, the overlap of A between the first and second pair here will not cause issues, because you mirror-sync A to B, respectively C, so A is not changing by the sync. Therefore, you can ignore said warning.
You are right @Plerry and I do do that. I actually have more than two destination folders, some on my LAN and some on my own 'cloud' server located overseas.
Of course when I do as you suggest, the syncs are still done sequentially, not simultaneously. But I least I don't have to attend to the transition from one folder to the next.
Since the transfer speed is not as fast as copying from one folder to another on the same PC, either on the LAN or over the internet, I was thinking that if they could be done simultaneously, they might all finish in the same amount of time as doing just one, the slowest one of course.
To make it faster for me now, I only copy to one on the LAN and one over the internet. Then I let those computers copy to the others that are close to them. I do it manually now. I can even start the A to B and C then go to B and double click synchronize which will wait for B to finish the proceed with the subsequent copies. And same for C. I've also been thinking of using RealTimeSync to handle the subsequent copies automatically.
Sometimes the files can be pretty large, even 100GB or more. Copying locally is generally okay, but over the internet I will often get a timeout of the semaphore error (can that be extended or is that inside Windows?). I guess the program is using a Windows file copy API function??? I was wondering if there is a more robust copy method available in FreeFileSync. If I'm really having problems I will use WinRAR to break the file into pieces, FTP it up to the my hosting server then FTP it down from the remote server then finally recombine it with WinRAR. That's very tedious. Sorry I'm a bit off topic in this last paragraph.
> Of course when I do as you suggest, the syncs are still done sequentially, not simultaneously.
Not correct.
When running the sync, the proposed sync actions of multiple left-right pairs are not performed in sequence of the left-right pairs, but in (seemingly) arbitrary order.
If you use the Donation or Business edition of FFS, sync actions may even be performed in parallel.
