BUG FIX: log file format

Discuss new features and functions
toby9999
Posts: 10
Joined: 20 Jul 2020

Post by toby9999

As mentioned in other posts, the addition of a log file format as HTML in v10.20 has caused a lot of problems.

The solution, should the developer wish to implement it, is to change the DEFAULT log file format back to Text (which it was prior to v10.20 when HTML was introduced).

Adding HTML didn't break things (and the developer even added the ability to change the file type between Text and HTML in v10.21) -- changing the *default* file type to HTML instead of leaving the default as Text is what caused many people's log processing scripts to break.

The developer should be more careful when changing default values.

I have wasted hours chasing this bug (with no response to my support emails or forum posts).

In case this helps others, the root cause in my case was that I was running *.ffs_real files as Windows Services under LocalSystem, which ignored the GlobalSettings.xml file under my normal user profile folder. FFS, upon not finding the settings file, ***defaulted*** back which meant it used HTML instead of Text (per the developer's change of the default value).

-- Toby
derousse
Posts: 2
Joined: 31 Jul 2020

Post by derousse

I'm running ffs_batch scripts using Task Scheduler and it's not picking up the Global setting either.

Please change the default file format back to Text!

Thanks,
Mike
toby9999
Posts: 10
Joined: 20 Jul 2020

Post by toby9999

Yeah, good luck getting the developer to fix this. He hasn't replied to any of my emails nor forum postings, nor has he fixed what he has broken.

In case it helps you, I launched FFS with the optional global settings switch and pointed it to a global settings file I created that had Text specified. In this way, it didn't matter that the Service was running under the LocalSystem user because the command switch overrode the typical location where FFS would normally look for the globalsettings.xml file.

For example, my ffs_real file (which runs as a Windows Service via the awesome NSSM tool) looks like this (notice how the ffs_batch job is called with the optional GlobalSettings.xml file specified)...

<?xml version="1.0" encoding="utf-8"?>
<FreeFileSync XmlType="REAL" XmlFormat="2">
<Directories>
<Item>D:\___ARCHIVE___</Item>
<Item>E:\FFS BACKUPS\___ARCHIVE___</Item>
</Directories>
<Delay>10</Delay>
<Commandline>"C:\Program Files\FreeFileSync\FreeFileSync.exe" "D:\OneDrive\_CONTROLLER\_FFS\_SCRIPTS\Sync_Archive.ffs_batch" "D:\___FFS GLOBAL SETTINGS___\GlobalSettings.xml"</Commandline>
</FreeFileSync>

Hope that helps.

P.S. Even though this gets us back to Text log files, yet another change by the developer has changed the end-of-line character, so in my case, my log parsing routine needed to be updated as well to be able to deal with the new EOL character (this has been mentioned by others in this forum too).
derousse
Posts: 2
Joined: 31 Jul 2020

Post by derousse

Toby,

I figured out that my batch job was running under a different account and I hadn't updated the correct GlobalSettings.xml file. After changing the setting in the correct xml file, it's picking up the log file format setting and all is well.

But thanks for the detailed information you shared, it could be very useful in the future.

Also thanks for the heads up about the change in the EOL character. I'll have to deal with that as well.

Thanks,
Mike
toby9999
Posts: 10
Joined: 20 Jul 2020

Post by toby9999

No worries ... just be careful running under a normal user account, it might not always work. That's why I run the service under LocalSystem (which gives the FFS job full administrator rights on the local computer). If I recall correctly, there's a helpful note in the developer's help file that discusses this issue (but don't quote me on that as I haven't looked at that in a long time). Cheers.