Repository navigation
fix(core): keep dangling symlink entries in list results - #8417
Merged
Merged
Conversation
Xuanwo
approved these changes
Oct 31, 2026
Contributor
Author
|
appreciate |
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.
Which issue does this PR close?
Closes #8412.
Rationale for this change
The issue traces the omission to
FsLister, but the entry is actually dropped one layer up.FsListeralready reports a dangling symlink correctly:DirEntry::metadatadoes not follow links, so the entry leaves the fs service asEntryMode::Unknown(verified locally — a dangling symlink reaches the operator layer asUnknown).The drop happens in
CompleteLister(core/core/src/layers/complete.rs). It stats everyUnknownentry to refine its mode, and the fs service's stat follows symlinks, so for a dangling symlink the stat returnsNotFoundand the lister treated that as "the entry is gone" and silently skipped it.A completion stat that misses its target only means the mode cannot be refined. The entry came from the service's own listing a moment earlier, so it should be kept as listed rather than dropped.
What changes are included in this PR?
opendal-core(CompleteLister): when the completion stat for anUnknownentry returnsNotFound, return the entry unchanged instead of dropping it. Other stat errors still propagate, and successful stats refine the mode exactly as before.test_list_includes_dangling_symlink, which lists a directory containing a dangling symlink throughOperatorand asserts the entry is present withEntryMode::Unknown. The test fails without the core change and passes with it.Are there any user-facing changes?
Listing a directory that contains dangling symlinks now returns those entries with
EntryMode::Unknowninstead of silently omitting them, restoring the pre-regression behavior described in #8412. No API changes.Breaking changes
AI Usage Statement
CompleteListerrather than in the fs lister, and implemented the fix and regression test with local verification (fs crate tests, opendal-core unit tests, and the fs behavior suite). The human author directed the work, reviewed the analysis, and remains responsible for the submission.Verification
Local verification (fs crate tests, opendal-core unit tests, fs behavior suite):