Ronald Oussoren added the comment:
This appears to be a bug in the APFS filesystem implementation.
On my machine:
- main disk (SSD, APFS): race condition happens
- r/w disk image with APFS: race condition happens
- r/w disk image with HFS+: no race condition
--
Ned Deily added the comment:
I was able to easily reproduce it as well. I suppose we all tested on very fast
SSD-based APFS file systems. I wonder if the problem might be file system
related. I wasn’t able to reproduce it using a HDD-based HFS+ file system but
it might just be due to the
Ronald Oussoren added the comment:
I've attached a variation on test-conc-read.py that uses os.open and low-level
APIs instead of the Python IO stack (open/io.open). This fails in the same way.
os.open/os.read/os.write/os.close are very thin wrappers around the
corresponding C APIs. That
Giovanni Pizzi added the comment:
Thanks for your feedback!
I also just reported the issue to Apple. For reference I got the Feedback ID
FB8009608.
I will let you know if they answer.
In any case I agree that also your other error is unexpected.
I am writing a library that should provide
Ronald Oussoren added the comment:
If it is reproducable in C this is likely a bug in macOS, and should be
reported to them.
I get the same behaviour as you with the test script, even if I add calls to
fhandle.flush and os.fsync to force the content to stable storage.
Interestingly enough
New submission from Giovanni Pizzi :
Hello,
when creating deleting (with `os.remove`/`os.unlink`) a file and opening it in
a different process at (almost) the same time, on Mac OS X relatively often I
get a file that is empty instead of either a `FileNotFoundError` exception, or
an open
