gh-300: Improve purge handling of unrecognized files - #389
Merged
Conversation
Punisheroot
marked this pull request as ready for review
July 31, 2026 10:51
zooba
reviewed
Jul 31, 2026
Member
|
Looks great, thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
uninstall --purge.Context
uninstall --purgecurrently removes recognized installs and known managed directories, but unrecognized content can remain behind. This includes files from incomplete or corrupted installations that are no longer returned by install discovery.The final cleanup cannot blindly remove everything that remains. Recognized runtimes still use the existing atomic-unlink path so that a runtime with locked executable files is not partially deleted. Unknown content may also contain a reparse point whose target is outside the managed install directory.
This change addresses the unrecognized-file cleanup described in #300. It intentionally does not add the optional less-destructive purge mode that would keep every recognized install; that interface and its exact preservation semantics can be considered separately.
Changes
Purge handling
The purge flow now records the prefixes of recognized installs whose removal raises
FilesInUseError. After the existing cleanup of recognized installs, cached downloads, global configuration, and shortcuts, it enumerates the remaining entries in the install directory and removes them except for those protected prefixes.This preserves the existing atomic-removal behavior for known runtimes while allowing broken or otherwise unrecognized content to be cleaned up.
Safe recursive deletion
rmtreenow treats directory symlinks and Windows junctions as leaf entries rather than traversing them. The link or junction itself is removed while its target is left untouched.The public
rglobbehavior remains unchanged because link following is still its default; only the deletion path opts into the non-following traversal.Tests
Added coverage for:
Validation
Performed on Windows with Python 3.14.6 and pytest 9.1.1:
tests/test_uninstall_command.py tests/test_fsutils.py: PASS (11 passed);403 passed,1 failed;git diff --check: PASS.The full-suite failure is the unrelated
tests/test_shellext.py::test_RegReadStr: the localHKCU\\Environment\\PATHvalue isREG_SZ, while that environment-specific test expectsREG_EXPAND_SZ.Compatibility and risk
The additional install-directory scan runs only for
uninstall --purgeand is linear in the number of direct entries. Normal install and uninstall operations are unchanged.Unknown files are deliberately removed by this destructive command, but recognized prefixes that could not be atomically removed are excluded from the final sweep. Junction behavior is exercised with real Windows junctions in temporary directories; creating a directory symlink was unavailable under the local Windows privilege configuration.