feat(core): remove on Windows through the authenticated handle (#445)
User description
Part of #359 (R-15 Gate 4, slice H1a-2), part 4 of 4, stacked on #1070. test-support only: no production caller, no production deletion release.
What this adds
Windows removal. The object is opened through the handle-relative lookup of every child (NtCreateFile, pinned directory as RootDirectory), with delete access and a share mode of read only: a writer that already has the file open makes the open fail (Busy), no later writer can open it while the handle is held, and the name cannot be renamed, deleted or replaced. The caller authenticates the bytes on that handle, then FileDispositionInfoEx (delete, POSIX semantics) is set on that same handle. No FILE_FLAG_DELETE_ON_CLOSE, no fallback to the classic disposition (Unsupported instead), a read-only file is refused, a directory only while empty. There is no quarantine directory and none of the Unix window. Result durability is NotConfirmed (no directory sync through a read handle).
FFI: one new unsafe call (SetFileInformationByHandle, one fixed FILE_DISPOSITION_INFO_EX; no generic wrapper), SAFETY comment states handle lifetime, rights, structure, size (layout pinned by a test) and call-lifetime. No new package.
Proof (hosted windows-latest is the oracle)
Rebind attempts (rename / delete / replace) fail while the handle is held; nobody can open the file for writing during the authentication and at the check; counter-proof: a handle opened with write sharing lets a writer change the bytes; a writer already open โ Busy, nothing changed; a delete-sharing reader does not stop the removal and the name is free at once; directory only while empty; read-only file refused; leftover removal Unsupported. The platform-neutral cases of remove.rs (refused / failing / wrong-identity authentication, link / junction / directory / missing name, hard links, filled directory) now run on Windows too.
Status: H1A_2_WINDOWS_REMOVAL=IMPLEMENTED_TEST_SUPPORT_ONLY, H1_PROVED=NO, R1_PRODUCTION_RECLAMATION=NOT_ADMITTED, GATE4_TERMINAL=NO.
Summary by Sourcery
Implement authenticated Windows removal in test-support while preserving fail-closed behavior and explicit durability limitations.
New Features:
- Add authenticated Windows file and empty-directory removal to test-support, using the held handle to prevent changes or name rebinding before deletion.
Enhancements:
- Report Windows removal durability as unconfirmed and retain unsupported status for leftover removal or unavailable POSIX delete semantics.
Documentation:
- Document the Windows removal guarantees, limitations, status, and hosted-runner evidence for Gate 4.
Tests:
- Run platform-neutral removal coverage on Windows and add tests for handle locking, competing writers, directory emptiness, read-only files, disposition layout, and unsupported leftovers.
Chores:
- Record the Windows removal implementation in the unreleased changelog.
Summary by cubic
Implements Windows file and directory removal in test-support only, where every removal previously refused with Unsupported.
- Opens each entry through the handle-relative lookup with delete access and read-only sharing, authenticates the bytes on that handle, then applies
FileDispositionInfoEx(POSIX delete) on the same handle; a writer already holding the file makes removal failBusy. - Adds the only new
unsafecall (SetFileInformationByHandlewith one fixed structure whose layout is pinned by a test), with the SAFETY comment covering handle lifetime, rights, structure, and size. - A counter-proof test demonstrates that write sharing would have let a writer change the bytes between authentication and delete.
- The platform-neutral removal tests in
remove.rsnow run on Windows; no quarantine directory exists there, so leftover removal staysUnsupportedand durability reportsNotConfirmed.
CodeAnt-AI Description
Add authenticated file and empty-directory removal on Windows for test-support
What Changed
- Files are deleted only after their contents are authenticated; while checked, they cannot be changed, renamed, or replaced. If another writer already has a file open, removal fails without changing it.
- Authentication failures leave files untouched. Read-only files are refused, and non-empty directories are not removed.
- Windows removal tests now cover these behaviors. Successful removals report that directory durability is unconfirmed; leftover-file removal remains unsupported.
Impact
โ
Prevents file changes between authentication and deletion
โ
Preserves files when authentication fails or a writer is active
โ
Avoids removing non-empty directories
๐ก Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.