Improve test compatibility for 16K block size filesystems

[wszqkzqk]

When building dust on systems using 16K filesystem block sizes, (tested on Arch Linux for Loong64) multiple tests fail during cargo test due to hardcoded 4K block size expectations. The test failures occur because Dust's output reflects actual disk usage (16K blocks), while tests expect 4K-based values.

Affected Tests

• test_main_basic
• test_main_long_paths
• test_main_multi_arg
• test_substring_of_names_and_long_names

Error Snippet:

failures:

---- test_substring_of_names_and_long_names stdout ----
output(stdout):
 0B   ┌── long_dir_name_what_a_very_long_dir_name_what_happens_when_this_goes_..
16K   │ ┌── hello
16K   ├─┴ dir
16K   ├── dir_name_clash
16K   │ ┌── hello
16K   ├─┴ dir_substring
48K ┌─┴ test_dir2

does not contain any of:
0B   ┌── long_dir_name_what_a_very_long_dir_name_what_happens_when_this_goes..
4.0K   │ ┌── hello
4.0K   ├─┴ dir
4.0K   ├── dir_name_clash
4.0K   │ ┌── hello
4.0K   ├─┴ dir_substring
 12K ┌─┴ test_dir2

0B   ┌── long_dir_name_what_a_very_long_dir_name_what_happens_when_this_goes..
4.0K   ├── dir_name_clash
4.0K   │ ┌── hello
8.0K   ├─┴ dir
4.0K   │ ┌── hello
8.0K   ├─┴ dir_substring
 24K ┌─┴ test_dir2

thread 'test_substring_of_names_and_long_names' panicked at tests/test_exact_output.rs:83:5:
assertion failed: will_fail
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- test_main_multi_arg stdout ----
output(stdout):
 0B     ┌── a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
16K     ├── hello_file│██████████████████████████████████████████████████ │ 100%
16K   ┌─┴ many        │██████████████████████████████████████████████████ │ 100%
16K ┌─┴ test_dir      │██████████████████████████████████████████████████ │ 100%

does not contain any of:
0B     ┌── a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── hello_file│█████████████████████████████████████████████████ │ 100%
4.0K   ┌─┴ many        │█████████████████████████████████████████████████ │ 100%
4.0K ┌─┴ test_dir      │█████████████████████████████████████████████████ │ 100%

0B     ┌── a_file    │                ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── hello_file│                ░░░░░░░░░░░░░░░░█████████████████ │  33%
8.0K   ┌─┴ many        │                █████████████████████████████████ │  67%
 12K ┌─┴ test_dir      │█████████████████████████████████████████████████ │ 100%

thread 'test_main_multi_arg' panicked at tests/test_exact_output.rs:83:5:
assertion failed: will_fail

---- test_main_basic stdout ----
output(stdout):
 0B     ┌── a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
16K     ├── hello_file│██████████████████████████████████████████████████ │ 100%
16K   ┌─┴ many        │██████████████████████████████████████████████████ │ 100%
16K ┌─┴ test_dir      │██████████████████████████████████████████████████ │ 100%

does not contain any of:
0B     ┌── a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── hello_file│█████████████████████████████████████████████████ │ 100%
4.0K   ┌─┴ many        │█████████████████████████████████████████████████ │ 100%
4.0K ┌─┴ test_dir      │█████████████████████████████████████████████████ │ 100%

0B     ┌── a_file    │                ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── hello_file│                ░░░░░░░░░░░░░░░░█████████████████ │  33%
8.0K   ┌─┴ many        │                █████████████████████████████████ │  67%
 12K ┌─┴ test_dir      │█████████████████████████████████████████████████ │ 100%

thread 'test_main_basic' panicked at tests/test_exact_output.rs:83:5:
assertion failed: will_fail

---- test_main_long_paths stdout ----
output(stdout):
 0B     ┌── /tmp/test_dir/many/a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
16K     ├── /tmp/test_dir/many/hello_file│███████████████████████████████ │ 100%
16K   ┌─┴ /tmp/test_dir/many             │███████████████████████████████ │ 100%
16K ┌─┴ /tmp/test_dir                    │███████████████████████████████ │ 100%

does not contain any of:
0B     ┌── /tmp/test_dir/many/a_file    │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── /tmp/test_dir/many/hello_file│██████████████████████████████ │ 100%
4.0K   ┌─┴ /tmp/test_dir/many             │██████████████████████████████ │ 100%
4.0K ┌─┴ /tmp/test_dir                    │██████████████████████████████ │ 100%

0B     ┌── /tmp/test_dir/many/a_file    │         ░░░░░░░░░░░░░░░░░░░░█ │   0%
4.0K     ├── /tmp/test_dir/many/hello_file│         ░░░░░░░░░░███████████ │  33%
8.0K   ┌─┴ /tmp/test_dir/many             │         █████████████████████ │  67%
 12K ┌─┴ /tmp/test_dir                    │██████████████████████████████ │ 100%

thread 'test_main_long_paths' panicked at tests/test_exact_output.rs:83:5:
assertion failed: will_fail


failures:
    test_main_basic
    test_main_long_paths
    test_main_multi_arg
    test_substring_of_names_and_long_names

It may be better to adapt to 16K block size in tests.

[bootandy]

cry.

These are 'test_exact_output' tests. dust/tests/test_exact_output.rs

They already have an 'ubuntu' output and a 'mac_and_some_linux' output. I guess we could add support for 16K block size.

Perhaps I could work out what the block size is 'meant' to be from something like this:
https://serverfault.com/questions/29887/how-do-i-determine-the-block-size-of-an-ext3-partition-on-linux
and make the tests detect .

What do you think is best ?

We could hard code your above examples as another 'or' option in main_output and similar functions.

[wszqkzqk]

We could hard code your above examples as another 'or' option in main_output and similar functions.

This does not seem to completely solve the problem, because users may also use other block sizes such as 32k and 64k.🤔🤔🤔

Perhaps I could work out what the block size is 'meant' to be from something like this:
https://serverfault.com/questions/29887/how-do-i-determine-the-block-size-of-an-ext3-partition-on-linux
and make the tests detect .

We may not be able to assume that the file system is ext2/3/4, perhaps we can try following command instead:

stat -f -c '%S' .

[bootandy]

This does not seem to completely solve the problem, because users may also use other block sizes such as 32k and 64k.

But realistically ? Is that likely ? - By the time users move away from 16K we'll have deprecated 4K. I also don't yet support 128 bit builds. But it's going to happen at some point.

The tests that fail show 'real' output - output as it exactly should be. That's why they are in the test_exact_output file.

So on reflection I don't want to use stat to try and calculate what the blocks 'should' be - (Although this would be ok to use in other test files), but not this one.

So I think in the places in that file that say vec![mac_and_some_linux, ubuntu] you should add 16k_block_linux to the list.