Symptom:
If I run TortoiseBlame on many of the files in my repository, the first line of output in blame always has 3 extra characters at the end of the first line, usually something like "[NUL] P" where '[NUL]' is the single-character glyph representing U+0000.
I think this is being caused by Tortoise, perhaps when doing string math, failing to take into account the 3-byte UTF8 BOM markings that are present on every file I've tested. The files have UTF8 BOM bytes from Visual Studio's default text encoding for C# files/projects.
This screenshot shows an example of this - the first line is "using System;[NUL] P":
This screenshot shows the contents of that same Program.cs file as it currently is in the repository, in a hex editor. We can see that the first three bytes are 0xEF 0xBB
0xBF, which is the UTF8 BOM, followed by the characters "using System;\r\n". There is no [NUL] character
contained in the file, nevermind the sequence "[NUL] P":
Here's another file where the first bytes of the file are the 3-byte BOM followed by "\r\nMicrosoft":
And that file's hex dump:
....
If I manually edit out the 3 bytes from the UTF8 BOM and commit the file, then TortoiseBlame operates correctly:
I've tested this at home and at work, on 5 machines total; on 5 different SVN repos (all containing C# code). It shows up everywhere that I've got BOMs and no where that I don't.
I don't think this bug is new; I remember seeing it months and months ago, I just never had the time to dig into it until today.
I should note that this is not affecting me in any way particular; Tortoise seems to work just fine otherwise.
In case the screenshots dont show up correctly in the body of this post, the files are directly attached.
-- Tortoise version --
TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45
ipv6 enabled
Subversion 1.14.0, -release
apr 1.6.5
apr-util 1.6.1
serf 1.3.9
OpenSSL 1.1.1g 21 Apr 2020
zlib 1.2.11
SQLite 3.29.0
-- Windows version --
Windows 10 1909 (18363.900)