[AmirF194]

Picking up from the thread on #2001: the abort happens after discovery finishes clean, in cbm_pipeline_build_semantic_manifest's own control-file walk.

semantic_manifest_walk_controls recursively walks the whole repo looking for .gitignore/.cbmignore/package-manifest files. When it hits the locked directory and cbm_opendir fails, it returns CBM_NOT_FOUND, which propagates all the way up and aborts the entire index. discover.c's walk_dir already treats the identical failure as "nothing to discover here" and moves on; the control walk had no reason to be stricter; a permission-denied subdirectory just has no control files to contribute.

Fix skips a nested directory it can't open instead of failing the whole walk. The root call still fails closed (depth 0), so pipeline_semantic_manifest_rejects_non_directory_root keeps passing unchanged.

Added pipeline_semantic_manifest_skips_unreadable_subdirectory: a locked sibling next to a readable one, asserts the walk succeeds and still finds the sibling's .gitignore. Needs a non-root run to mean anything, since root ignores the chmod and the check would be a no-op (same reasoning as test_cli.c's existing root-demotion comment); verified that way in a container both ways.

Not fixed here, and worth flagging so it doesn't get lost: #2020 is the separate issue about the generic error hint collapsing distinct failure codes. It's real and independent of this one; I only touched the abort itself.

Fixes #2001

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thank you for the focused control-file walk change and the pipeline test. We need more time to review how an unreadable directory should affect indexing and exclusion handling before giving a decision.

The review queue is currently full, so detailed feedback may take a little time. We are working through it carefully and appreciate the work you have put into supporting the project. Thank you for your patience.

[AmirF194]

The test-windows-guards failure is the same pre-existing section_cold_storm issue as its sibling PR #2084, unrelated to this diff. Anything else needed here?

[DeusData]

Thank you for asking what is still needed. The current recursive control-file walk aborts when an opendir fails, so the supplied case addresses a concrete path. I do not have an additional contributor task to request from this triage: review of exclusion/error semantics and attribution of the Windows result are now maintainer-owned.

[DeusData]

Thanks again for the focused unreadable-subdirectory case. There is still no additional contributor task from this triage: the exclusion/error-semantics review and CI attribution remain maintainer responsibilities. The separate diagnostic issue #2020 remains outside this change.

[DeusData]

Thank you, @AmirF194, and sorry this sat for so long after the go-ahead. The fix is exactly the right size: a nested directory the walk cannot open has no control files to contribute, so skipping it matches what discovery already does, while the root call (depth 0) still fails closed. The test is well chosen too, with a locked directory next to a readable sibling whose .gitignore must still be found, and your note about it needing a non-root run saved us a false green.

What we changed on your branch, so you know what landed:

1. Merged current main in (one merge commit, signed off). main had reformatted the old if (!dir) return CBM_NOT_FOUND; line in semantic_manifest_walk_controls(), so the branch no longer merged cleanly. We resolved the conflict by keeping your hunk word for word; your commit is untouched and the diff against main is still just your change and your test.

That is the only change. Before pushing it we checked the merged tree by indexing a directory with one subdirectory locked to mode 0: with the old code the run aborts and publishes nothing, with your fix it indexes normally. Your new test fails against the old code and passes with yours.

We will merge once CI is green on the new head. Thanks again for tracking this down from #2001 and for keeping the separate diagnostics issue (#2020) out of this change.