Skip to content

Conversation

@Connor-GH
Copy link

No description provided.

This was caught when testing chmod inside of Redox OS.
Previously, doing `chmod 10777 file` will cause an error stating that
"mode is too large (4607 > 7777", which is both incorrect and contains
a missing parenthesis. We now print the large octal value in terms of
octal.
@github-actions
Copy link

GNU testsuite comparison:

Skipping an intermittent issue tests/shuf/shuf-reservoir (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/sort/sort-stale-thread-mem (passes in this run but fails in the 'main' branch)

@sylvestre
Copy link
Contributor

could you please add a test to make sure we don't regress in the future? thanks

@ChrisDryden
Copy link
Collaborator

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

@Connor-GH
Copy link
Author

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

I had something similar, I have just been really busy. I am a university student.

@Connor-GH
Copy link
Author

The test case results in this:

running 1 test
test test_chmod::test_chmod_permissions_too_large ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 4097 filtered out; finished in 0.01s

@codspeed-hq
Copy link

codspeed-hq bot commented Jan 16, 2026

CodSpeed Performance Report

Merging this PR will improve performance by 4.01%

Comparing Connor-GH:print_numeric-fix (7913280) with main (fe748f4)

Summary

⚡ 1 improved benchmark
✅ 281 untouched benchmarks
⏩ 38 skipped benchmarks1

Performance Changes

Mode Benchmark BASE HEAD Efficiency
Memory numfmt_large_numbers_si[10000] 4.9 MB 4.7 MB +4.01%

Footnotes

  1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@Connor-GH
Copy link
Author

Connor-GH commented Jan 16, 2026

So the OpenBSD CI is failing because 7777 is considered to be in invalid value:

  thread 'test_chmod::test_chmod_permissions_too_large' panicked at tests/by-util/test_chmod.rs:310:45:
  Command was expected to succeed. code: 1
  stdout = 
   stderr = chmod: Inappropriate file type or format (os error 79)

Which is EFTYPE errno
This happens here in the OpenBSD code: https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/sys/ufs/ufs/ufs_vnops.c#L465

// <snip>
if (cred->cr_uid && !vnoperm(vp)) {
		if (vp->v_type != VDIR && (mode & S_ISTXT)) // S_ISTXT == 0o1000
			return (EFTYPE);
// <snip>

This gets triggered because:

  1. we are not uid 0
  2. !vnoperm(vp) passes
  3. we are not a directory
  4. we have S_ISTXT set because (0o7777 & 0o1000) == 0o1000.

They are aware of this, see https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/regress/lib/libc/sys/t_mkfifo.c#L225-L229

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants