Per VognsenYet another reminder that you have to think about file IO as a concurrency problem: https://thomask.sdf.org/blog/2019/11/09/take-care-editing-bash-scripts.html
In the inverse genre (tailing a log file where readers observing concurrent writes is a feature, not a bug) there's also this terrifying but entertaining lightning talk from @bcantrill: https://www.youtube.com/watch?v=vm1GJMp0QN4&t=2475s
Surge 2013: LightningTalks
Conor Stokes@pervognsen @bcantrill if only there was an OS that got this significantly more right than the others (it's Windows, Windows gets it significantly more right than the others).
@DirtyPunk @bcantrill Windows certainly has much stricter semantics around sharing. E.g. the equivalent of the mmap truncate SIGBUS wouldn't happen on Windows because SetEndOfFile fails if there are any open mappings, so the truncate would fail if there were concurrent mapping-based readers. But this bondage and discipline philosophy around sharing is a double-edged sword. When you think about it, it's crazy that read permission to a log file can block the log writer from truncating it.
@pervognsen @bcantrill Oh, I'm aware of that, I still think Windows got this right and the people pointing at *that infamous issue* got it wrong.
The only issue there is with UI.
POSIX file handling semantics are *fundamentally broken and you can not build correctness on top of them*.
@pervognsen @bcantrill This is why you can use a file based DB like Access or sqllite on a Windows-to-Windows network drive connection and the same thing is fundamentally not possible on nearly any UNIX.