Have you tried watching the whole directory with the logs ? File "writes" come in different ways, so it might be the file is actually re-created.

I cannot read from stdout for irrelevant reasons, so I need to look into a file called 'latest.log', which is a text file.
[..] need extremely quick responses and I'd rather not poll multiple times per second

I can definitely not recommend watching file changes for high-frequency monitoring. Example from a project for doing stdout/err monitoring asynchronously. Your windows defender will scan ever file access and the IO overhead is too high. If you're lucky your OS might at least keep the content in memory and thus prevent re-reading it every time. Though that is completely dependent on the size of the file, which as you can see yourself, will go to staggering numbers depending on your server, mods etc. As you also figured out: There is no notion of getting a "stuck reading" instead of EOF. A file has the content its provided at that time or it doesn't, nothing in between - at least not that I know of such behaviour or that it would make any sense in regards to synchronisation and deadlocking (you're essentially expecting the OS to deadlock your program indefinitely).

Have you tried watching the whole directory with the logs ?

I just tried watching the whole directory, but that lead to the same result,
where the 'latest.log' gets modified when the file gets closed (when I close my game client)
and recreated (when I reopen it).

I can definitely not recommend watching file changes for high-frequency monitoring. Example from a project for doing stdout/err monitoring asynchronously.

As much as I'd like to just read the stdout/err, I don't start the minecraft client process.
It is done through launchers.
So even if I were to start the launcher, it would separate me from the minecraft client's stdout/err anyways.
Launching client myself is not an option, because I'm trying to be compatible with already used launchers.

Since you've also said that a system dependent deadlock sounds silly and probably doesn't exist,
then my only option remain the original variable duration poll-watcher
or (if even possible) connecting to stdout of an existing process.
I'll be investigating the second option and currently I found sysinfo crate for finding the process.
Although irrelevant to this Git, if you have any advice on what I can use for this please let me know.
And thank you for the help so far. 😃

Quick update:
I've made few google searches.
Getting stdout of a Windows process is extremely janky and error prone, it seems I'll have to go with the first solution.

I can currently reproduce this problem using C# and FileSystemWatcher, running notify & the c# version side by side.

Another fun thing is that the debug.log file itself has 0KB size, until I click on it inside explorer.exe, then its refreshed and suddenly both applications also receive a change event.

Repro https://www.youtube.com/watch?v=3x_48HhXoA4 Simply Pressing F2 to start a rename triggers an file size refresh in explorer and events for both programs.

What I do not know is how notepad++ is still able to realize file changes.

I'd be curious if watchers from other language runtimes (like golang) are able to see changes to the file in the use case you describe. Usually a file being written on windows can't be read by other processes at all until the file is closed. Since you can read it (with explorer and notepad++) I presume the file was opened with the FILE_SHARE_READ share access flag.

The C# version from microsoft themself isn't able to do so, as shown above. I guess notepad++ tries to poll or open the file, which activates probably a flush in the OS.