Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Two LOCAL fingerprint mode tests assume a 0022 umask and fail under 0002

Closed Beginner friendly
  • Is something wrong?
#350 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #382 by @iceboundrock — merged

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
testing

Research direction

Read the two named tests in tests/test_local.py and the _mode_text implementation in src/autoforge/local_workspace.py. Run them under umask 0002 and 0022 to confirm the failures and current behavior. Update the tests so restoring the original mode preserves the starting fingerprint under either umask; both tests should pass in both runs.

Written by the indexing model from the issue text.

Description

bug

Two tests fail when pytest inherits umask 0002 and pass under 0022:

  • tests/test_local.py::test_fingerprint_notices_a_mode_change_on_an_already_dirty_file
  • tests/test_local.py::test_a_mode_change_is_bound_even_with_core_filemode_disabled

Each makes a file executable, then restores a hard-coded 0644 and expects the original fingerprint. That only holds if the file started as 0644. The property they check, that LOCAL's fingerprint moves on chmod +x and moves back when the change is undone, still holds under 0002. The failures were found in the M0 baseline on #339, and PR #345's review ran into them again.

What happens

Each test takes a fingerprint of a file, chmods the file to 0755 and checks that the fingerprint moved. It then chmods the file to 0644 and asserts the fingerprint equals the first one (tests/test_local.py:308 and :3393). The fingerprint records each inspected file's full permission bits: _mode_text in src/autoforge/local_workspace.py:317-318 writes S_IMODE as four octal digits. Under umask 0002 the file is created 0664, so after the round trip it is 0644, not its original mode. Both assertions then compare two different fingerprints and fail.

I reproduced it on main at 6fddbc9, with CPython 3.12.15, in a fresh worktree. Under umask 0002, both tests fail, at :308 and :3393. Under umask 0022, both pass.

Evidence

  • This host's login umask is 0002 (Debian 13.7). M0's first full run inherited it, and both tests failed. A bounded rerun with a child-only umask of 0022 passed both (M0 report, section 5, items 2–3). Every later measured run here set 0022, which is why the two tests don't appear in #345's A/B or in make check.
  • PR #345's review reproduced the same pair under an inherited 0002, and saw both pass under 0022.
  • CI passes both. I haven't checked the hosted runner's umask.

Impact

Run from a shell with umask 0002, make check reports two failures in LOCAL's fingerprint tests that say nothing about the change under test. A developer has to recognise them, or run with a narrower umask, which the repository doesn't document.

Desired outcome

Both tests pass under any umask pytest inherits, and they still prove that undoing the mode change restores the original fingerprint.

Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 46m
Merged PRs (30d)
82

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.