This is my first time using FreeFileSync, coming from GoodSync. I have re-created the sync/backup jobs from GoodSync to backup some of my local folders via SFTP. This works so far. Via Windows 10 Scheduler, i could create also a Job, which starts directly after logging in to my Windows 10 Home Account. I have created a Windows 10 scheduler job for every sync job in FreeFileSync. But it seems, that only the first job is running. At least if i start FreeFileSync after logging in, only one of the jobs has the last synced date for today, all the other ones are from 4 days ago.
Or do i have to create only 1 Windows 10 scheduler Job and within this multiple program start actions?
Or can i concatenate multiple jobs in one *.ffs_batch file?
Autostart multiple sync/backup jobs?
- Posts: 4
- Joined: 28 Aug 2021
-
- Posts: 4867
- Joined: 11 Jun 2019
They are likely all working. If they are running at the same time, the GUI will usually only reflect one of them since that status is saved in a file, which can only be locked by one process at a time
-
- Posts: 2946
- Joined: 22 Aug 2012
You can also run multiple stored FFS sync configurations as a single FFS sync job, by listing the multiple FFS sync configurations when invoking FFS.
See here.
You then have only one instance of FFS, and a log including all the sync activities.
Alternatively, you can schedule separate FFS syncs, and then schedule those such that running the different FFS instances never overlaps in time.
See here.
You then have only one instance of FFS, and a log including all the sync activities.
Alternatively, you can schedule separate FFS syncs, and then schedule those such that running the different FFS instances never overlaps in time.
- Posts: 4
- Joined: 28 Aug 2021
Is this a file called "sync.ffs_db"? TO my understanding, this file exists for every sync pair in the synced folders. Or is there another file at a global location?They are likely all working. If they are running at the same time, the GUI will usually only reflect one of them since that status is saved in a file, which can only be locked by one process at a time xCSxXenon, 29 Aug 2021, 14:26
- Posts: 4
- Joined: 28 Aug 2021
Ahh that's nice to know. Many thx for that. Is this also true for RealTimeSync? For my multiple directory pairs, I would like to have on 3 of them a monitoring to keep changed local files in sync.You can also run multiple stored FFS sync configurations as a single FFS sync job, by listing the multiple FFS sync configurations when invoking FFS.
See here.
You then have only one instance of FFS, and a log including all the sync activities. Plerry, 30 Aug 2021, 07:44
-
- Posts: 2946
- Joined: 22 Aug 2012
> Is this also true for RealTimeSync?
Yes it is. You can define multiple folders to watch (using the green "+" icon); essentially as many as you like.
However, if that is a smart thing to do is the question.
Any change in any of the monitored folders (or any of their subfolders) will then cause the defined Command-line action to be run, normally launching an FFS sync. And obviously, this FFS sync would then normally also need to have the same, very wide scope, that includes all monitored folders.
Normally it makes more sense to keep the scope of RTS monitored folders, and the corresponding scope of the FFS synced folders, as limited as possible, such that the FFS sync is not launched very often, and when it runs, it will run fast, as the scope is limited.
But, in rare cases, it may still cause multiple instances of FFS running simultaneously, and thus potentially causing the observed log-file issues.
Yes it is. You can define multiple folders to watch (using the green "+" icon); essentially as many as you like.
However, if that is a smart thing to do is the question.
Any change in any of the monitored folders (or any of their subfolders) will then cause the defined Command-line action to be run, normally launching an FFS sync. And obviously, this FFS sync would then normally also need to have the same, very wide scope, that includes all monitored folders.
Normally it makes more sense to keep the scope of RTS monitored folders, and the corresponding scope of the FFS synced folders, as limited as possible, such that the FFS sync is not launched very often, and when it runs, it will run fast, as the scope is limited.
But, in rare cases, it may still cause multiple instances of FFS running simultaneously, and thus potentially causing the observed log-file issues.
-
- Posts: 4867
- Joined: 11 Jun 2019
No, the sync.db file tracks moveing and renaming for the location that it is stored in so you don't have to do a delete and copy for those operations. It just speeds things up. The file is in AppData or the FFS install location I believe, or it may be stored in the sync job files themselves.
