14.6 issues diagnostic message

[TheAncient]

For your information:
I believe when you published version 14.6 you left a diagnostic message active:

In my nightly sync jobs, FFS is called from a batch file. After upgrading to 14.6, after each and every call,
[E.G.: Call "C:\Program Files\FreeFileSync\FreeFileSync.exe" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\Config Files\$MACHINE\GlobalSettings-MACHINE-Nightly.xml" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\Config Files\$MACHINE\name_of_batch.ffs_batch"
I now get a diagnostic message as follows:
{
"syncResult": "success",
"startTime": "2025-12-04T10:59:58-07:00",
"totalTimeSec": 19,
"errors": 0,
"warnings": 0,
"totalItems": 2,
"totalBytes": 16291,
"processedItems": 2,
"processedBytes": 16291,
"logFile": "C:\\$$MYLogs\\name_of_batch 2025-12-04 105958.728.html"
}

After reverting to version 14.5, I no longer get this diagnostic message.

You may have forgotten to disable this diagnostic message when you published version 14.6 of FFS.

[xCSxXenon]

https://freefilesync.org/manual.php?topic=scripting

Nope! New feature added. It's a JSON chunk of data for post-processing if you desire

[TheAncient]

Is there any easy way to turn it off? (I am getting about 20 versions of this chunk of data in my nightly batch output)
Having extra info WHEN NEEDED is great but when it is NOT needed, it's just clutter.

[therube]

Can you just redirect output to nul (/dev/nul)?

go.bat > nul

Would something like that work?


> In my nightly sync jobs

Am I right in assuming that this only happens if you use Windows Task Scheduler?

As in, when I run directly from command-line, C: prompt, I'm not seeing any additional output unless I specifically redirect the batch file's standard output.

go.bat | more
go.bat > json.log.txt
.

C:\DEV\BACKUP\FreeFileSync.exe C:\DEV\BACKUP\FFS_PROFILES\12Batch.ffs_batch


[TheAncient]

You are correct:
Task Scheduler starts a "nightly batch" file. This batch file then calls FFS as described in my original post. (Call "C:\Program Files\FreeFileSync\FreeFileSync.exe" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\Config Files\$MACHINE\GlobalSettings-MACHINE-Nightly.xml" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\Config Files\$MACHINE\name_of_batch.ffs_batch")
The call describes the location of the FFS program file, the location of the Global Settings file and the location of the ffs_batch file.
The location of the log file is specified as an argument when Task Scheduler triggers the batch file.
Your suggestion of redirecting the output of the call to nul i.e. adding "> nul" to the end of the call sounds promising. I will try that as soon as I have the time to do so. I just hope that won't suppress any messages I actually need to see in the log file.

[xCSxXenon]

If this is running via batch script from a scheduled task, how are you even seeing that output in the first place? The documentation shows the 'pipe' operator being required, and your snippet doesn't show you are using that. Can you clarify where this info is being presented and how you are seeing it?

[TheAncient]

Task Scheduler, in PROPERTIES/ACTIONS/ADD ARGUMENTS specifies "> C:\LogFolder\BatchName-%Date%.log 2>&1" (See attached screen print).
I did run a test where I routed the output of the call to > nul and this did, in fact suppress the new diagnostic message. The only thing I'm afraid of at this point is, that it might also suppress messages that I SHOULD look at at. Oh well, we'll cross that bridge when we get to it. For now I'm in business.
Thanks for your help!

[Zenju]

Redirecting STDOUT(1) to "nul" is fine, since potential errors would be written to STDERR(2). But this latter communication channel is rarely used by FFS. Only severe application errors (*not* synchronization errors) would be streamed there.

Therefore a construct like the following should yield the old behavior:

2> C:\LogFolder\BatchName-%Date%.log > nul


[TheAncient]

I'm afraid the method you suggested won't work:
The nightly batch file already opens "C:\LogFolder\BatchName-%Date%.log" and directs all output, including the STDOUT output of the called FFS batches, to that file. The re-direction you suggested (2> C:\LogFolder\BatchName-%Date%.log > nul) then tries to RE-open the same log file that is already open and that doesn't work.

Here is the call (modified with your suggested re-direction) in my nightly batch file:
Call "C:\Program Files\FreeFileSync\FreeFileSync.exe" "%XML-Location-Machine%\GlobalSettings-%MACHINE-NAME%-Nightly.xml" ^
"%ffs_batch-Location-Machine%\BatchName.ffs_batch" ^
2> C:\$$USERLogs\$$Sync%MACHINE-NAME%-MAIN-%Date%.log > nul

And this is output I am getting:
C:\$$USERLogs>Call "C:\Program Files\FreeFileSync\FreeFileSync.exe" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\
Config Files\$MACHINE-NAME\GlobalSettings-MACHINE-NAME-Nightly.xml" "Z:\09 System\015 Directory Tools\$$ Synchronization\FreeFileSync\
Config Files\$MACHINE-NAME\BatchName.ffs_batch" 2>C:\$$USERLogs\$$SyncMACHINE-NAME-MAIN-2025-12-07.log 1>nul
The process cannot access the file because it is being used by another process.

Rather than spending a lot of time on this, I'll just tack the >Nul at the end of the CALL command(s).
If I understand things correctly, this should re-direct the STANDARD Output (including the JSON diagnostics) to the NULL device but still display Standard ERROR messages in the log.

[Zenju]

I'm only vaguely following what you're doing. Sticking only "> nul" at the call to FFS will supress the json info, but leave STDERR(2) alone, which you seem to be capturing by the caller of the batch file. So that should do the trick.