GNU testsuite comparison:

Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

GNU testsuite comparison:

Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

I think your PR is only a partial solution and it breaks some functionality that currently works.

Before your changes:

$ cargo run -q --features=unix chmod 755 -R dangling_symlink 
chmod: cannot operate on dangling symlink 'dangling_symlink'
$ echo $?
1
$ cargo run -q --features=unix chmod 755 -R -P dangling_symlink 
chmod: cannot operate on dangling symlink 'dangling_symlink'
$ echo $?
1

After your changes:

$ cargo run -q --features=unix chmod 755 -R dangling_symlink
$ echo $?
0
$ cargo run -q --features=unix chmod 755 -R -P dangling_symlink
$ echo $?
0

And what GNU chmod does:

$ chmod 755 -R dangling_symlink 
chmod: cannot operate on dangling symlink 'dangling_symlink'
$ echo $?
1
$ chmod 755 -R -P dangling_symlink 
$ echo $?
0

Ah I did not fully understand the flag interaction mentioned at the bottom of the issue, thank you for the examples. Will fix that up tonight, and add the extra unit test for that failure case

A couple of different learnings while fully grokking the flag combinations here:

1. chmod was using the traversal default from chown, which is not the same
   a. https://www.man7.org/linux/man-pages/man1/chmod.1.html "... -H is the default."
   b. https://man7.org/linux/man-pages/man1/chown.1.html "... -P is the default."
2. chmod -R -H doesn't seem to work correctly, repro below

I have added tests for each of these scenarios, plus extended the unit tests for all of the positive and negative unit tests for all the dangling link scenarios.

For functionality, I have fixed the original bug, and I have fixed the default traversal flag. I have not yet fixed the -H bug, but have traced it to the file_path == file_path.canonicalize().unwrap_or(file_path.to_path_buf()) test within walk_dirs, which is not doing what was intended. Will explore more to close this out!

chmod -R -H Repro

Given:

$ mkdir -p example/tmp
$ cd example 
$ touch tmp/{a,b}
$ ln -s tmp arg_symlink             
$ ls -l
total 4
lrwxrwxrwx 1 me me    3 Apr  2 02:00 arg_symlink -> tmp
drwxrwxr-x 2 me me 4096 Apr  2 02:00 tmp
$ ls -l tmp
total 0
-rw-rw-r-- 1 me me 0 Apr  2 02:00 a
-rw-rw-r-- 1 me me 0 Apr  2 02:00 b

uutils behavior on main:

$ cargo run -q --features=unix chmod u+x -R -H arg_symlink
$ ls -l
total 4
lrwxrwxrwx 1 me me    3 Apr  2 02:00 arg_symlink -> tmp
drwxrwxr-x 2 me me 4096 Apr  2 02:00 tmp
$ ls -l tmp
total 0
-rw-rw-r-- 1 me me 0 Apr  2 02:00 a
-rw-rw-r-- 1 me me 0 Apr  2 02:00 b

coreutils behavior on 9.6:

$ which chmod
/home/me/Documents/builds/coreutils-9.6/src/chmod
$ chmod u+x -R -H arg_symlink
$ ls -l    
total 4
lrwxrwxrwx 1 me me    3 Apr  2 02:00 arg_symlink -> tmp
drwxrwxr-x 2 me me 4096 Apr  2 02:00 tmp
$ ls -l tmp                  
total 0
-rwxrw-r-- 1 me me 0 Apr  2 02:00 a
-rwxrw-r-- 1 me me 0 Apr  2 02:00 b

GNU testsuite comparison:

Congrats! The gnu test tests/chmod/symlinks is no longer failing!

Because the chmod -P -H finding is entirely new, and the fix will focus on lines mostly unrelated to this diff (within walk_dir) and I haven't started much work on it, I'm going to file a separate issue. I've removed the new -P -H tests that examined a symlink command argument, and can re-add those while fixing the follow-on issue

This PR should be ready to review again!

GNU testsuite comparison:

Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/chmod/symlinks is no longer failing!

I created a Lima VM locally to match the SELinux build steps and see what the test failure is. Tried to match the GH workflow as much as possible, but had to install the rust toolchain myself in the VM.

$ limactl start --plain --name=default --cpus=1 --disk=30 --memory=4 --network=lima:user-v2 template://fedora
$ lima mkdir work
$ limactl copy -r ./* default:~/work/

And then after running the test suite, I wasn't able to reproduce the test failure:

$ cd work && cargo test --features 'feat_selinux'
...

test result: ok. 3435 passed; 0 failed; 44 ignored; 0 measured; 0 filtered out; finished in 221.65s

Is it possible that this is a test flake? What's the best way to proceed here?

Congrats! The gnu test tests/chmod/symlinks is no longer failing!

Great :) And thanks for your PR!