parallel-disk-usage: Test case usual_cli::multiple_names sorts expected value incorrectly on some file systems

It looks like the test case usual_cli::multiple_names() is failing on aarch64-linux devices. See this log: https://logs.ofborg.org/?attempt_id=ea8d0c05-ebcb-4177-bf7a-b618bd8f8ff8&key=nixos%2Fnixpkgs.280371

Unfortunately, I don’t have an AArch64 device capable of compiling the project and can’t reproduce this myself.

What’s interesting to me is that the actual value seems to be the correct (sorted) output, whereas the expected value seems to be in the wrong order.

About this issue

Original URL
State: closed
Created 5 months ago
Comments: 20 (12 by maintainers)

Most upvoted comments

test succeeds if run in a vm with ext4 fs. machine it is failing on is using zfs and btrfs.

This was a great hint and I was able to figure it out now. The test code sorts each individual data_tree (nested/, flat/, empty_dir/), but not the root data_tree.

So, why was it working on most systems and only failing on some? That seems to have to do with different file systems reporting different sizes for the SampleWorkspace. I inspected the actual output of the test on a system with an ext4-filesystem with cargo test multiple_names -- --show-output. This is the result:

---- multiple_names stdout ----
ACTUAL:
 40      ┌──empty-dir│██████████                                                               │ 14%
  3      │ ┌──3      │█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                                         │  1%
126      ├─┴flat     │████████████████████████████████                                         │ 43%
  6      │   ┌──1    │██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░                                         │  2%
 66      │ ┌─┴0      │█████████████████░░░░░░░░░░░░░░░                                         │ 23%
126      ├─┴nested   │████████████████████████████████                                         │ 43%
292    ┌─┴(total)    │█████████████████████████████████████████████████████████████████████████│100%

EXPECTED:
 40      ┌──empty-dir│██████████                                                               │ 14%
  3      │ ┌──3      │█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                                         │  1%
126      ├─┴flat     │████████████████████████████████                                         │ 43%
  6      │   ┌──1    │██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░                                         │  2%
 66      │ ┌─┴0      │█████████████████░░░░░░░░░░░░░░░                                         │ 23%
126      ├─┴nested   │████████████████████████████████                                         │ 43%
292    ┌─┴(total)    │█████████████████████████████████████████████████████████████████████████│100%

Note that the two folders nested/ and flat/ are actually reported to have the exact same size! Therefore, they already are in the correct order and no sorting is required. The test succeeds. In comparison, in the failing test output, you can see that these folders have different sizes (due to a different file system), and therefore the EXPECTED value is not sorted correctly.

That also means, you can actually reproduce this failure on any system, by making sure the size of flat/ is larger than nested/ on all systems, e.g. by just adding a single byte:

--- a/tests/_utils.rs
+++ b/tests/_utils.rs
@@ -79,7 +79,7 @@ impl Default for SampleWorkspace {
                 "0" => file!("")
                 "1" => file!("a")
                 "2" => file!("ab")
-                "3" => file!("abc")
+                "3" => file!("abcd")
             }
             "nested" => dir! {
                 "0" => dir! {

I will add a PR with a fix in a minute 😃

peret on Feb 10, 2024