Using FFS to update its own ffs_batch file

Discuss new features and functions
Posts: 74
Joined: 17 Mar 2008

mfreedberg

Hello again! Interesting question, hope this makes sense.

We are deploying a sync solution that uses both RealTiimeSync and
FreeFileSync, and we are already running into scenarios where we would like to
make changes to the ffs_batch and ffs_real files. While we could do this with
our software distribution solution, I wondered if we could just roll into the
ffs_batch config. We would include in our ffs_batch a folder pair for the
local installation folder for our RealTimeSync/FreeFileSync and a server
folder which would host only current ffs_batch and ffs_real files. Every time
we would run a sync, the last folder pair would be to mirror the server
folder with our master copies of our config files to the local folder.

In order for that to work, however, we would need to be able to replace those
files while the tools are running and I am not sure if that is kosher or not.

Do RealTimeSync and FreeFileSync read in the respective config file into
memory and execute from there during a run or do they keep the config file
locked while they aru running? If they simply "load" a config from the file
and do not reference the file contents again until the next time the
application runs, then I think our strategy for auto-updates to our config
files could work.

Thoughts?
Posts: 74
Joined: 17 Mar 2008

mfreedberg

So sorry for the run on bolding, did not notice that...if there is a way to
edit the post, please let me know.
User avatar
Site Admin
Posts: 7061
Joined: 9 Dec 2007

Zenju

FFS never relies on the configuration files to remain the same during
execution. Loading of the files basically is as you describe, for both RTS and
FFS batch, the config file is read just once at the beginning in an read-
exclusive mode. So reading config either succeeds during this small time-
frame, blocking other write requests, or it fails while other applications
were faster opening the config file for write access. In other words, it's
transactional.
It's a different story for FFS GUI mode. There is one place, where a
configuration is read a second time, namely when loading a ffs_batch via gui.
If the user goes to advanced-> create batch job... the batch-specific settings
are retrieved by a second load.
So in short, your idea should work.