Issue with du and who tests

[Arcterus]

On my Linux computer, four of the tests for du fail, despite them passing on Travis.

I am specifically trying to fix test_du_basics_subdir() right now (the others may be similar, but I have not checked yet). When I run the command outside of cargo test, it seems to work fine. It also seems to work fine during cargo test when the full path to the original fixture (subdir/deeper) is specified. However, for whatever reason, du thinks the block size of subdir is 0 with the current setup, so the output ends up being 4\tsubdir/deeper\n rather than 8\tsubdir/deeper\n. I am unable to replicate this issue outside of cargo test, which is posing some difficulties.

The test for who -m also fails, but it seems to be because the current TTY has no name, as changing line 321 from if !self.my_line_only || cur_tty == ut.tty_device() { to if !self.my_line_only || (cur_tty == ut.tty_device() && cur_tty.len() > 0) { appears to fix the issue. Again, this only occurs for me under cargo test. I'm thinking it might be because the tester forks or something.

[bergey]

I also find that several du tests fail. Sample output below. Strangely, I get yet a third answer when I run uutils du outside cargo test In every case I've looked at, the uutils du gives the same answer as gnu du on my machine.

I wonder if having the test suite compare to gnu du (or any other implementation) would be more stable.

---- test_du::test_du_basics_subdir stdout ----
current_directory_resolved: 
run: /home/bergey/code/active/coreutils/target/debug/uutils du subdir/deeper
thread 'test_du::test_du_basics_subdir' panicked at 'assertion failed: `(left == right)`
  left: `"0\tsubdir/deeper\n"`,
 right: `"8\tsubdir/deeper\n"`', tests/test_du.rs:50:5

[Arcterus]

I'm not sure why this was closed, as it is still not fixed. The problem (or at least part of the problem) is that different filesystems and filesystem options lead to different expected results. I'm not sure what the best solution is, seeing as I believe the output is correct. It really might be best to simply compare with the GNU coreutils implementations if they are present on the system.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.