Repository navigation
fix(libkernel): keep the Windows vnode watch when the watched file is deleted - #5393
Conversation
… deleted Windows 10 1903 deletes a file with open handles by moving it into $Extend\$Deleted until the last handle closes, so the next snapshot of a watched file that a title (or the test) deleted saw a new path, tried to watch that directory's changes, got ERROR_ACCESS_DENIED and threw from the watch thread, which aborts the process; the path change was also reported as NOTE_RENAME next to NOTE_DELETE. A snapshot with a pending delete or no links now reports NOTE_DELETE alone and drops the parent directory watch instead of replacing it, as the file has no directory to be renamed or removed from any more.
|
Independent Windows stress validation by OpenAI Codex (AI-assisted). No code changes were made to this PR. Validated PR head |
|
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.
|
|
Independent confirmation on Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, full build (AI-assisted: Claude Code). Without the fix, enabling the existing With the same change as this PR ( Since that test now passes on Windows, it could move out of the |
What
On Windows 10 1903 and later,
DeleteFileWand_wremovedelete with POSIX semantics: a file with open handles is moved into\$Extend\$Deleteduntil its last handle closes. TheEVFILT_VNODEwatch thread keeps a handle on the watched file and takesGetFileInformationByHandleExsnapshots every 50 ms, so after the title deletes a watched file the next snapshot sees a new final path (\\?\C:\$Extend\$Deleted\<id>, 0 links, delete pending), replaces the parent directory watch with one on that directory, getsERROR_ACCESS_DENIEDfromFindFirstChangeNotificationand throws from the detached watch thread, which aborts the process. The path change was also reported asNOTE_RENAMEnext toNOTE_DELETE.A snapshot with a pending delete or no links now reports
NOTE_DELETEalone and drops the parent directory watch instead of replacing it: the file has no directory left to be renamed or removed from, and its own handle keeps reporting until the knote is deleted. The vnode entry indocs/dev/debt/libkernel.mdrecords the behaviour.Measured on Windows 11 with a probe (second handle with
FILE_SHARE_DELETE, thenDeleteFileWor_wremove):GetFinalPathNameByHandleWreturns\\?\C:\$Extend\$Deleted\<id>,FileStandardInforeportsNumberOfLinks0 andDeletePending1, andFindFirstChangeNotificationWon\\?\C:\$Extend\$Deleted\fails with error 5. The same abort appeared as an intermittentguest_kqueuefailure (EVFILT_VNODE: FindFirstChangeNotification failed, error=5, exit 0xc0000409) on a Windows CI run of my fork at the end of a vnode test, where the kqueue is closed and the file removed right after, with the watch thread still in a snapshot.Tested
guest_kqueuegainsDeleteWatchedFile, registered on Linux and Windows: a watched file is unlinked while open,NOTE_DELETEis reported once withoutNOTE_RENAME, nothing more is reported afterwards, and the descriptor and the kqueue close normally.Full Linux and Windows builds with every test on my fork's GitHub Actions
Buildworkflow (1077 and 1095 tests, all passed; this branch together with three kqueue branches of mine): https://github.com/yixx16/AnyPS5/actions/runs/38445944846. The Windows abort without the fix is in the first attempt of https://github.com/yixx16/AnyPS5/actions/runs/38437850775 (jobwindows,guest_kqueue). No title run.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)