TC's log sometimes add characters 0x00

[thomasmolover]

I want to merge some log files, but the size of the merged files is abnormal. So I found that some log files contain illegal characters of 0x00.
My log file is saved in UTF-8 format.

[ghisler(Author)]

That shouldn't be, only UTF-16 files should contain 0 characters. Can you post an example of a line containing a 0 character, please?

[thomasmolover]

here's one of the error files

https://drive.google.com/file/d/1I1HImPDztTqPxCM9u3qV8JQLpj2rRuhA/view?usp=sharing

[gdpr deleted 6]

Notice that there is a block of 62 null-bytes between the log lines:

2020/01/22 09:02:52: 程序关闭 (Thomas Mo/THOMASMO)

(English translation: Program shutdown)

and

2020/01/22 09:51:49: 程序启动 (Thomas Mo/THOMASMO) UTF-8

(English translation: Program start)

Something happened between TC shutting down and TC starting up again there with the log file. Well, it was back in January, so i guess it would be rather difficult for you to remember what you did then at this time between those two log line timestamps, or what the environment and settings with regard to TC were.

Unless Ghisler/other users will be able to reproduce the issue, without knowing more it will probably be very hard or perhaps even impossible to pinpoint the cause of what happened to your log file.

It might be something related to TC. But it might very well also be some other (buggy) program/script trying to access the log file, opening it in read+write mode or write mode and accidentally either writing an "empty" byte buffer or extending its file size. Therefore, allow me to ask: What software are you using to access the log files (for merging or otherwise), and how exactly are you using that software?

[ghisler(Author)]

It looks like some kind of incomplete flush of the file data, e.g. because of a computer crash.

[gdpr deleted 6]

2ghisler(Author)
It doesn't look like an incomplete flush. Note that the last line before the null-byte-block is the typical and complete(!) log line indicating shutdown of TC.

UPDATE: It could actually be an incomplete flush due to a crash right at the moment TC is starting up. (See below)

[Usher]

But it is an incomplete flush. There should be something like that:

Code: Select all

2020/01/22 09:02:52: 程序关闭 (Thomas Mo/THOMASMO)
2020/01/22 09:05:29: 程序启动 (Thomas Mo/THOMASMO) UTF-8

The program reserved space for the second line, filled it with 0x00 bytes, but didn't have time to write the text and CRLF.
It's exactly the same length.

[gdpr deleted 6]

2Usher
Indeed. I didn't notice that. The length of the null-byte-block is exactly the same as the log line informing about starting up TC.
You are right, it could possibly be a crash with an incomplete flush right at the time TC was starting up and trying to append the startup log line to the log...