Repository navigation
fix(libkernel): change O_APPEND on a Windows file through fcntl - #9256
Conversation
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
|
Independent Windows run of this PR (head da61bf7). Environment: Windows 11 10.0.26300, Ryzen 7 9800X3D, WinLibs GCC 15.2.0 r7 (MinGW), Release, BUILD_TESTING=ON. Results:
Note for anyone repeating the baseline: that failing run aborts after writing Not run: Linux/macOS, AI-assisted: yes |
|
Thanks for the independent run and the baseline. Before this PR, Windows only expected the throw at that point, so the test could not stop partway and leave the probe file behind. Now it can, so ddcb41a removes The |
|
Hi @Dom3005, a merge-order note for two of mine:
AI-assisted: yes |
|
Works for me: no dependency either way, and whichever merges second keeps both test changes and every debt sentence in the AI-assisted: yes |
fcntl(F_SETFL) threw when it changed O_APPEND on a Windows file. The guest flag already chooses WriteAtEnd, but a descriptor opened with O_APPEND also carries the CRT's append flag, so _write kept appending after the guest cleared it. F_SETFL now replaces the CRT descriptor of every descriptor sharing the open file's status with a duplicate handle opened with or without _O_APPEND, as libc fdopen does for append mode. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ddcb41a to
69cdebd
Compare
What
On Windows,
fcntl(F_SETFL)threwfcntl: changing O_APPEND on a file is not implementedwhenever it set or clearedO_APPENDon a regular file. FreeBSD 11.4'skern_fcntlchangesO_APPENDlike any otherF_SETFLflag.The guest flag already decides whether
writegoes throughWriteAtEnd. A descriptor opened withO_APPENDalso carries the CRT's append flag, though (NativeOpenpasses_O_APPENDto_open_osfhandle), so after the guest clearedO_APPEND,::_writewould still seek to the end. The CRT flag has to stay set whileO_APPENDis on, becausefdopen(fd, "w")on such a descriptor writes through the CRT and must keep appending.When
O_APPENDchanges on a Windows file,F_SETFLnow duplicates the descriptor's handle, opens it with or without_O_APPENDthrough_open_osfhandle, and_dup2s it onto the same number. This is the same patternMoveAppendingHandlein libc uses forfdopenin append mode. On FreeBSDO_APPENDbelongs to the open file, so this is done for every descriptor that shares the status (the descriptorsdupandF_DUPFDcreate). The duplicated handle keeps the same file object, so file position andflocklocks carry over.The "Changing
O_APPENDon a Windows file" clause is removed from thefcntlentry indocs/dev/debt/libkernel.md.Tested
Windows 11 10.0.26200, WinLibs GCC 15.2.0 r7 UCRT, Release,
BUILD_TESTING=ON, onmaincecb540.guest_kernel_fcntlnow runs the sameO_APPENDchecks on every host, where it used to expect the throw on Windows: append, clearO_APPENDand write at offset 0, set it again through aF_DUPFDduplicate and check that the original descriptor appends, clear it through the duplicate and check that the original no longer appends, then read the file back (Ybcdeabc).fcntl: changing O_APPEND on a file is not implemented, fd=3.ctest -E '^agc_driver': 1230/1230 passed.python tools/check_conventions.py: passed.O_APPENDsemantics, which the host's ownF_SETFLprovides.Overlap:
tools/pr_overlap.pyshows #8544 and #9109 editing the same paragraph ofdocs/dev/debt/libkernel.md(#8544 changes the pipeF_GETFLpart of thefcntlentry), so whichever merges second needs a one-line rebase. #6044, #6977 and #8520 share files, but their diffs don't touchO_APPEND.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code