By default we open log files with 0 share access, this means you can't even tail the file from an external process, this changes it to full share so one could even remove it while open (win will not actually delete until we release the handle though).
If the user sets the log file using HARMONY_LOG_FILE env var and makes any calls to the FileLog handler, this was a guaranteed crash due to the prior locking issue. Even though this will now fix the lock issue the obsolete handler would likely still cause issues as StreamWriter doesn't really expect others to write the file while its using it.
unrelated, the upstream harmony always appends the log file, vs HarmonyX which truncates on each start. I prefer the HX behavior but wanted to note the difference.
This fixes two issues:
By default we open log files with 0 share access, this means you can't even tail the file from an external process, this changes it to full share so one could even remove it while open (win will not actually delete until we release the handle though).
If the user sets the log file using
HARMONY_LOG_FILEenv var and makes any calls to the FileLog handler, this was a guaranteed crash due to the prior locking issue. Even though this will now fix the lock issue the obsolete handler would likely still cause issues as StreamWriter doesn't really expect others to write the file while its using it.unrelated, the upstream harmony always appends the log file, vs HarmonyX which truncates on each start. I prefer the HX behavior but wanted to note the difference.