Batch mode

Discuss new features and functions
Posts: 22
Joined: 18 Dec 2009

grobbla

Hello,

when loading a ffs_batch file, some settings are not editable via GUI, i.e.
"Silent mode", "Log dir", "Error handling", what would be nice.
Choosing "Create batch job" from a loaded ffs_batch file, shows source/target
lines, but the mentioned settings are not reflected.

My proposal would be to rename "Create batch job" to i.e. "Edit batch job",
reflecting the settings from a file loaded on painting the dialog.

Is it possible to disable the 50% check when running a batch job in
unattended mode?

Is there a list of return codes from the exe file?

Thanks for your time,

regards,

fred
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

>some settings are not editable

If loaded from GUI the batch job is implicitly converted to a *.ffs_gui file
stripping off the *.ffs_batch-only parts.
If the batch job is loaded from "Create batch job" no conversion takes place
and all settings will be editable.

> disable the 50% check

Either hide the dialog permanently when it comes up or set this XML key in
GlobalSettings.xml to false: < CheckForSignificantDifference >

> list of return codes

These are the important ones:

- 0: sync successful
- -4: sync aborted
- -5: sync completed with errors

Generally for all error situations the returncode will be negative.
Posts: 22
Joined: 18 Dec 2009

grobbla

> If loaded from GUI the batch job is implicitly converted to a *.ffs_gui file
stripping off the *.ffs_batch-only parts. If the batch job is loaded from
"Create batch job" no conversion takes place and all settings will be
editable.

I see, yes this works.

> Either hide the dialog permanently when it comes up or set this XML key in
GlobalSettings.xml to false: < CheckForSignificantDifference >

Ah, I did not know that this is a global setting, even for batch jobs. Maybe
you want to put this setting on a job basis, to keep it more flexible.

> These are the important ones:

Thank you, the more detailed, the better for batch jobs. Please put the rc
codes into the readme, for the next version.

regards,
fred
Posts: 22
Joined: 18 Dec 2009

grobbla

Hello,

a solution for keeping the setting "< CheckForSignificantDifference >" private
to batch files, is not to operate in the exe directory. My batchfiles for
backup jobs is not in the exe directory, so starting them without changing to
the exe directory creates a file "GlobalSettings.xml" in the batch file dir.
Changing the setting in this file to false, will be "private" for batch jobs.
Using the GUI, I will see the warning.

regards,
fred
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

@ grobbla: this is true for the portable version that saves globalsettings.xml
and LastRun.ffs_gui in current working directory (in comparison to installer-
version that saves them in %appdata%\FreeFileSync regardless of the working
directory.

Concerning granularity of CheckForSignificantDifference: It's a design
question: Currently this setting is treated like all the other global warning
dialogs that can be re-enabled via a gui setting. When making it lokal to a
syncjob one has to answer questions like "how to reset this setting" and "how
to integrate this new "type" into GUI without regression".
Posts: 22
Joined: 18 Dec 2009

grobbla

> this is true for the portable version that saves globalsettings.xml and
LastRun.ffs_gui in current working directory (in comparison to installer-
version that saves them in %appdata%\FreeFileSync regardless of the working
directory.

Oops, I was not aware the zipped version is for portable use, what I prefer
though. I generally do not like installers and use zip versions where
available.

> When making it lokal to a syncjob one has to answer questions like "how to
reset this setting" and "how to integrate this new "type" into GUI without
regression".

It could be made a checkbox in the batch dialog. Batch jobs return errorlevel
-4 in this occasion, at the moment. If it would exit with a distinct
errorlevel, one could know what happend, without having to look at the log
files. In my case, more than one job is running in a queue, so its not easy to
find the right logfile for a job.

regards, fred