Ah, reminds me of a Windows bug that I chased in Win2000 Server. (For all I know it might still be there - I've stopped writing Windows code in 2007).
When you wrote to a file (using WriteFile or fwrite()), it first extended the file length, and then committed the buffer. This is supposed to be atomic - that is, you should never be able to see the length already extended but the data not yet there. And it apparently was atomic if both reads and writes came from the local machine, or both came from the network - however, if the write was on the local machine but the read was from the network, locking was missing, and it WAS possible to read zeros instead of the real data (but only because of a race condition - reading the same file again later would give the expected answer)
Tried to get Microsoft to at least confirm this bug, to no avail - there was no one interested in talking to a lone freelance developer back then.
When you wrote to a file (using WriteFile or fwrite()), it first extended the file length, and then committed the buffer. This is supposed to be atomic - that is, you should never be able to see the length already extended but the data not yet there. And it apparently was atomic if both reads and writes came from the local machine, or both came from the network - however, if the write was on the local machine but the read was from the network, locking was missing, and it WAS possible to read zeros instead of the real data (but only because of a race condition - reading the same file again later would give the expected answer)
Tried to get Microsoft to at least confirm this bug, to no avail - there was no one interested in talking to a lone freelance developer back then.