Repository navigation
Conversation
…e from following symlinks
FileUtils.delete inspected the path through the File API, so a Windows directory junction was seen as a directory and the recursive delete followed it into the target. Read BasicFileAttributes with NOFOLLOW_LINKS and delete symbolic links and junctions as leaf entries instead. Add a Windows-only regression test that creates a junction with mklink /J and verifies the target is left untouched.
Mikkey-f
force-pushed
the
fix/1169-delete-no-follow-links
branch
from
October 25, 2026 08:00
bbd08cd to
3433cc0
Compare
This branch has not been deployed
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.
Purpose of the pull request
Closed: #1169. Supersedes #1170.
CompatibilityTest#readWithCacheAfterTempDeletiondeleted the whole system temp directory, andFileUtils.deletefollowed symbolic links during its recursive walk, so a link inside the deleted tree could take the deletion outside it (see #1169 for the macOS incident).This PR is based on @AhmedYoussef98's work in #1170, with their commit kept and authorship intact. It adds the Windows directory-junction guard requested in review: junctions are not symbolic links, so
Files.isSymbolicLink()misses them whileFile.isDirectory()still resolves them.What's changed?
CompatibilityTestnow deletes only Fesod's own temp directory (FileUtils.getTempFilePrefix()) instead ofjava.io.tmpdir(from fix: stop tests from deleting the system temp dir and FileUtils.delete from following symlinks #1170).FileUtils.deletereadsBasicFileAttributeswithLinkOption.NOFOLLOW_LINKSand treats symbolic links and "other" file-system entries as leaves. On Windows a directory junction reportsisDirectory=true, isOther=trueunder NOFOLLOW (a regular directory reportsisOther=false), so junctions are deleted themselves and never traversed.test_delete_doesNotFollowSymbolicLinks(POSIX; skipped where links cannot be created) from fix: stop tests from deleting the system temp dir and FileUtils.delete from following symlinks #1170.test_delete_doesNotFollowDirectoryJunctions(Windows-only): creates a junction withmklink /J(no admin rights required) and verifies the target file survives.Verification
expected: <true> but was: <false>(the target file was deleted); with the guard in place it passes.mvn clean package -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet: 60 common + 1,726 sheet tests, 0 failures, 1 skipped. The skip is the POSIX symlink test, which this Windows machine cannot create links for; CI's Linux runners execute it../mvnw spotless:checkandmvn javadoc:javadocpass.Checklist