Support mode ab+
equivalent through os.open
#1839
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think I understand now why IronPython uses sometimes two streams for accessing one file. I may be wrong, but this is what I think is the case:
O_APPEND | O_CREAT | O_RDWR
is one of them, tagged as modeab+
.Append
with read access.Append
with R/W by opening with a regularOpen
and then seeking to the end before every write. This is functionally the same as on POSIX but non-atomic, so it may lead to data loss in some circumstances.Append
, perhaps for consistency of API.ab+
by opening two streams, one for writing with proper file modeAppend
, and a secondary one for reading. Unlike MSVCRT, it does not suffer with problems with data overwrite.Given above, I decided to keep the two-stream solution, which seems to me is optimal for Win32. In this PR, I extend the two-stream solution to
os.open
(see added test, which is now passing). The usual workarounds for POSIX are still in place, but I still hope that for POSIX,ab+
can be implemented with one stream — something for another PR.Other changes in this PR is an explicit set of file position after accessing
SafeFileHandle
, which, according to the documentation should reset the position to 0. I have not observed this behaviour in the few tests I have run (on macOS/linux the position was unchanged), but I'd rather not argue with the documentation. Perhaps there are some situations when the position is moved. Therefore,SafeFileHandle
is now only accessed right after opening, before the descriptor/file is passed to the caller (with one exception ofdup2
, which may not even survive the winter).Finally, wherever I see it, I change the code to put the "platform agnostic" branch in the
else
clause.