BUG FIX: log file format

[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]

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]

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]

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]

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.