PROBLEM: Illegal Character in Log File Name (Windows)

[intexx]

The recent attention to the time portion of the log file name is appreciated, but the implementation has a problem. On the Windows platform, the colon (:) is an illegal character.

Request: Could you use a period (.) instead.

Thanks,
Jeff Bowman
Fairbanks, Alaska

[Zenju]

Did you actually try FFS and find an issue or is this just theoretical?

[intexx]

I've been using FFS for nearly five years now and I love it.

After closer examination, however, I find I must correct my original claim. The new character in the log files name is actually NOT a colon. It's U+02F8 on Windows' Character Map application.

Nevertheless, still it's causing trouble. It's not in the ANSI 1252 codepage and thus can't be interpreted by some text editors. Command line processing of the files is made more difficult, in some cases impossible.

All of these would be easily mitigated by simply using a period instead of the high-order character. It's a natural fit with the hyphens in the date portion of the timestamp.

[Sync 2015-02-12 05.14.51.log]

Thanks,
Jeff Bowman
Fairbanks, Alaska

[bgregory01]

I've been using FFS for nearly five years now and I love it.

After closer examination, however, I find I must correct my original claim. The new character in the log files name is actually NOT a colon. It's U+02F8 on Windows' Character Map application.

Nevertheless, still it's causing trouble. It's not in the ANSI 1252 codepage and thus can't be interpreted by some text editors. Command line processing of the files is made more difficult, in some cases impossible.

All of these would be easily mitigated by simply using a period instead of the high-order character. It's a natural fit with the hyphens in the date portion of the timestamp.

[Sync 2015-02-12 05.14.51.log]

Thanks,
Jeff Bowman
Fairbanks, Alaska

I have found this to be a problem also. I have written VB programs that read the log files created by FreeFileSync and they are all now not working. When I try to get the file creation time my program errors out due to an invalid file name (code 52 VB6). Hope this will be fixed. A period would suffice.
Thanks

[wm-sf]

I'm guessing Jeff and Rag are using more recent Win than my WinXP SP3.

Since 6.14 I don't get log files at all. When FFS starts a file without a date or time is created which is deleted at the end. This is while FFS was running

-rwxrwx---+ 1 Wm None 40609 Feb 11 09:26 bones2flash 2015-02-11 091149.log
-rwxrwx---+ 1 Wm None 0 Feb 13 21:03 bones2flash .log

that is from cygwin under Win, afterwards the last file is deleted leaving no log at all.

No log files defeats the purpose of a sync tool for me, if I can't run my routines unattended and check the logs afterwards what is the point?

If this doesn't get fixed I'm gone.

P.S. I didn't notice this right away because my script / batch file does things the nix way and produces nothing if everything is good, it wasn't until something happened that I *knew* should have produced a Warning that I had a closer look.

[volker01]

Yes, i have the same Problem with Version 6.14 in Windows. FFS startet as Admin with a batchfile and create Logfiles. Logfilenames are with colums! (Name of the batch - Date - Time like: 07:15:19) So Logfiles are unusable in Windows.

[Zenju]

The raised colon (U+02F8) that FFS is using is a regular Unicode character and should cause no problems with Unicode-aware programs.
I take it that you are seeing issues with legacy ANSI applications?

[bgregory01]

That's correct in my case. Have older VB programs that fail when trying to rename or access the date and time of the log file. I have reverted to the 6.14 Beta which doesn't use this "colon". I guess you could make it an option or use a "period" instead. You're the programmer and have done an excellent job with FreeFileSync. Do what you think is the best... or do nothing at all. Regardless I thank you for this program.

[wm-sf]

The raised colon (U+02F8) that FFS is using is a regular Unicode character and should cause no problems with Unicode-aware programs.
I take it that you are seeing issues with legacy ANSI applications?

But surely the raised colon *isn't* a colon as described in the ISO8601 extended format? It is just something that *looks* like a colon. I'd be perfectly happy with ISO8601 basic format, i.e. what we had before or at least the option to use it.

This is no different to expecting a unicode char that looks a bit like a vertical bar / pipe on a command line to work like the one the OS expects.

[Zenju]

Alright, since there are obviously a number of users doing path evaluations with programs that are not Unicode-aware, most notably cmd.exe, and the new log file name is just cosmetics, I'll revert to the old naming convention in the next release.

[wm-sf]

I'm in love with FFS again, happy belated valentine :)

Comment: although there may appear to be some backwardness in mainly english native language speakers not adopting high end characters in file names and similar there is also the older computing adage of wanting something to work the same in as many places and for as many people as possible in mitigation.

[Zenju]

I'm in love with FFS again, happy belated valentine :)

Comment: although there may appear to be some backwardness in mainly english native language speakers not adopting high end characters in file names and similar there is also the older computing adage of wanting something to work the same in as many places and for as many people as possible in mitigation.

hehe, I should break other features, too, then fix them :D

[eahm]

Alright, since there are obviously a number of users doing path evaluations with programs that are not Unicode-aware, most notably cmd.exe, and the new log file name is just cosmetics, I'll revert to the old naming convention in the next release.

Thank you Zenju, IMO the only alternative to FFS is Syncovery but after I setup all the logs notification system etc. I'd really really like to stick to this one.

Now, OT, the only thing missing is limiting the number of the days of the revision copies but that's another discussion :)

[bgregory01]

Thanks Zenju. That will be most helpful.

[intexx]

Alright, since there are obviously a number of users doing path evaluations with programs that are not Unicode-aware, most notably cmd.exe, and the new log file name is just cosmetics, I'll revert to the old naming convention in the next release.

> I'll revert to the old naming convention in the next release

Thank you, Zenju :-)

Thanks,
Jeff Bowman
Fairbanks, Alaska

[intexx]

Thank you Zenju, IMO the only alternative to FFS is Syncovery but after I setup all the logs notification system etc. I'd really really like to stick to this one.

Now, OT, the only thing missing is limiting the number of the days of the revision copies but that's another discussion :)

> IMO the only alternative to FFS is Syncovery

Just thought I'd weigh in here...

This was the first I'd heard of Syncovery. I had a brief look at it just now and my first impression is that it appears overpriced. It certainly is underpowered when stood up next to FFS.

Thanks,
Jeff Bowman
Fairbanks, Alaska

[wm-sf]

Alright, since there are obviously a number of users doing path evaluations with programs that are not Unicode-aware, most notably cmd.exe, and the new log file name is just cosmetics, I'll revert to the old naming convention in the next release.

Dunno about other people in this thread but my sync strategy doesn't involve sitting and watching.

No logs that can be checked means unknown. I'm using the competition now, just because it produces valid log files. Otherwise it is slower and munches memory, but at least I don't have to sit and watch the fucking thing like I do with FFS at the moment

How much effort does it take to correct a mistake?

The colons in the file name weren't even colons to begin with!

Damn and other swearwords.

Why the delay in repairing this cosmetic foolishness? If some people want something that looks like a colon but isn't in their filenames offer them the choice rather than break more than one file system and then dilly dally.

Did anyone even ask for this? And did they ask for what you actually gave them?

Please. I think people that use logs have waited a bit.

I'm moving on, I can't speak for others.

[Zenju]

Dunno about other people in this thread but my sync strategy doesn't involve sitting and watching.

No logs that can be checked means unknown. I'm using the competition now, just because it produces valid log files. Otherwise it is slower and munches memory, but at least I don't have to sit and watch the fucking thing like I do with FFS at the moment

How much effort does it take to correct a mistake?

The colons in the file name weren't even colons to begin with!

Damn and other swearwords.

Why the delay in repairing this cosmetic foolishness? If some people want something that looks like a colon but isn't in their filenames offer them the choice rather than break more than one file system and then dilly dally.

Did anyone even ask for this? And did they ask for what you actually gave them?

Please. I think people that use logs have waited a bit.

I'm moving on, I can't speak for others.

Why not do the simple thing and just use the previous version?

[mithrandir8]

I also just started seeing the issue with a log file being created during sync that is then deleted when the sync is done. The log name I can see while the sync is running is the name of the batch job with a space then .log at the end. For example "MyBackup .log"

Forgot to add that this is on a Windows machine, I had already posted in a different thread about a problem on a CentOS box where the logs have invalid characters in the name since the latest update. I understand that it is supposed to be fixed in the next update but I just wanted to add what I'm seeing on my Windows machine now.

[wm-sf]

Why not do the simple thing and just use the previous version?

I am now. I suppose it is because I don't understand why this was implemented in the first place, people using log files don't, as a rule, look for excitement and interest in file names. It just isn't of value. Given that no-one has said, "Curse you, I really love having something that looks like a colon but isn't in my file names" and you have produced some tests for other issues I thought this would be an easy inclusion. No matter now

[nukeskywalker]

I also just started seeing the issue with a log file being created during sync that is then deleted when the sync is done. The log name I can see while the sync is running is the name of the batch job with a space then .log at the end. For example "MyBackup .log"

Forgot to add that this is on a Windows machine, I had already posted in a different thread about a problem on a CentOS box where the logs have invalid characters in the name since the latest update. I understand that it is supposed to be fixed in the next update but I just wanted to add what I'm seeing on my Windows machine now.

I have the same issues here.

FFS runs on two computers, one with WinXP Pro SP3, and the other one with Windows 7 Pro SP1, both running the current FFS version, v6.14! Both sync their files and save the logfiles to the same local drive, connected to my WinXP-PC through USB, while it is shared in my private network, so Win7 is accessing the drive via local network.
Both processes are periodically started through the Windows task planer.

On Win7, FFS is running as normal privileged user (not admin), syncing only the home folder, and the created log files look as usual, with date, time etc.
(btw., I use Notepad++ and (sometimes) Windows Notepad, and have no problems opening the log files with the 'fake' colon sign)

But on WinXP, FFS is running with admin rights, syncing two root folders from C: (the option "copy locked files" is enabled), and the created log files look as described above:
"BackupC .log", "BackupC _0.log", "BackupC _1.log", and so on...

No date or time, only the script name, followed by a blank, underscore and an increasing number.
But with previous FFS versions on XP, the log files had date and time in the filenames!

Is it anywhere possible to manually change the filename mask of the created logfiles?

Thank You...

[intexx]

I have the same issues here.

FFS runs on two computers, one with WinXP Pro SP3, and the other one with Windows 7 Pro SP1, both running the current FFS version, v6.14! Both sync their files and save the logfiles to the same local drive, connected to my WinXP-PC through USB, while it is shared in my private network, so Win7 is accessing the drive via local network.
Both processes are periodically started through the Windows task planer.

On Win7, FFS is running as normal privileged user (not admin), syncing only the home folder, and the created log files look as usual, with date, time etc.
(btw., I use Notepad++ and (sometimes) Windows Notepad, and have no problems opening the log files with the 'fake' colon sign)

But on WinXP, FFS is running with admin rights, syncing two root folders from C: (the option "copy locked files" is enabled), and the created log files look as described above:
"BackupC .log", "BackupC _0.log", "BackupC _1.log", and so on...

No date or time, only the script name, followed by a blank, underscore and an increasing number.
But with previous FFS versions on XP, the log files had date and time in the filenames!

Is it anywhere possible to manually change the filename mask of the created logfiles?

Thank You...

> Is it anywhere possible to manually change the filename mask of the created logfiles?

Darn good idea, Nuke. This should be made a feature request.

Log filename masking solves the issue once and for all. It relieves Zenju of the burden of trying to appeal to everyone (he who builds by every man's advice is going to end up with a crooked house).

Folks doing things like parsing the logs and saving the info to a database are confident that their implementation won't break due to an unexpected filename sometime down the road.

The filename can be customized according to each user's preference; all configurations on all OSs are immediately supported.

Granted this example is overkill, but have a look here: [404, Invalid URL: http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html]. (FYI used by the good folks over at Amazon.)

While still a bit excessive for our needs, this one's a bit more sane: MSDN Standard Format Strings.

But I think you're onto something. Everyone wins with log filename masking.

Thanks,
Jeff Bowman
Fairbanks, Alaska

[wm-sf]

There is a Win beta mentioned over in Help if anyone is interested.