btrfs causes four test failures

[dcampbell24]

I tried running cargo test --features unix --release on my desktop and laptop and had failures on my desktop only. These installs are both exactly the same, but my desktop runs on btrfs and my laptop on ext4. They are running the most recent update of Debian 12 bookworm. This is on the most recent stable version of Rust.

Here is the output:

...
failures:

---- test_cp::test_cp_debug_reflink_auto_sparse_always_non_sparse_file_with_long_zero_sequence stdout ----
touch: /tmp/.tmp8FzIzn/a
write(append): /tmp/.tmp8FzIzn/a
write(append): /tmp/.tmp8FzIzn/a
run: /home/david/projects/coreutils/target/release/coreutils cp --debug --sparse=always a b
thread 'test_cp::test_cp_debug_reflink_auto_sparse_always_non_sparse_file_with_long_zero_sequence' panicked at tests/by-util/test_cp.rs:4046:5:
assertion `left == right` failed
  left: 40
 right: 8

---- test_cp::test_cp_sparse_always_empty stdout ----
write(default): /tmp/.tmpjXdqIm/src_file1
run: /home/david/projects/coreutils/target/release/coreutils cp --sparse=always src_file1 dst_file_sparse
open: /tmp/.tmpjXdqIm/dst_file_sparse
thread 'test_cp::test_cp_sparse_always_empty' panicked at tests/by-util/test_cp.rs:2334:9:
assertion `left == right` failed
  left: 32
 right: 0

---- test_cp::test_cp_sparse_always_non_empty stdout ----
write(default): /tmp/.tmp7HMecc/src_file1
run: /home/david/projects/coreutils/target/release/coreutils cp --sparse=always src_file1 dst_file_sparse
open: /tmp/.tmp7HMecc/dst_file_sparse
thread 'test_cp::test_cp_sparse_always_non_empty' panicked at tests/by-util/test_cp.rs:2361:5:
assertion `left == right` failed
  left: 136
 right: 16

---- test_du::test_du_dereference_args stdout ----
mkdir: /tmp/.tmpfF3pUp/dir
write(default): /tmp/.tmpfF3pUp/dir/file-ignore1
write(default): /tmp/.tmpfF3pUp/dir/file-ignore2
symlink: /tmp/.tmpfF3pUp/dir,/tmp/.tmpfF3pUp/sublink
run: /home/david/projects/coreutils/target/release/coreutils du -D -s sublink
run: /home/david/projects/coreutils/target/release/coreutils du -H -s sublink
run: /home/david/projects/coreutils/target/release/coreutils du --dereference-args -s sublink
run: /home/david/projects/coreutils/target/release/coreutils du -s sublink
thread 'test_du::test_du_dereference_args' panicked at tests/by-util/test_du.rs:367:12:
'4	sublink
' does not contain '0	sublink
'


failures:
    test_cp::test_cp_debug_reflink_auto_sparse_always_non_sparse_file_with_long_zero_sequence
    test_cp::test_cp_sparse_always_empty
    test_cp::test_cp_sparse_always_non_empty
    test_du::test_du_dereference_args

test result: FAILED. 3384 passed; 4 failed; 57 ignored; 0 measured; 0 filtered out; finished in 33.95s

[kralo]

run: /home/david/projects/coreutils/target/release/coreutils du -s sublink thread 'test_du::test_du_dereference_args' panicked at tests/by-util/test_du.rs:367:12: '4 sublink ' does not contain '0 sublink '

I loooked into the test_du::test_du_dereference_args . I can reproduce it on btrfs, i.e. with TMPDIR=/mnt/p2/btrfstmp/ cargo test test_cp

I will mention @sylvestre as the author of commit eea8d40.

It looks to me as if the check for a size of =0 is overly specific, as even GNU's du will report '4':

# du --version
du (GNU coreutils) 8.22
[..]
# du -s sublink 
4	sublink
# df -T sublink/
Dateisystem    Typ   1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/nvme1n1p1 btrfs  48827084 5521616  43070208   12% /mnt/p2

[AnirbanHalder654322]

I am the author of the test_cp_debug_reflink_auto_sparse_always_non_sparse_file_with_long_zero_sequence test, that specific test wasn't created with taking cow filesystems like btrfs into account as I simply didn't have access to a non ext4 system. The other test_cp tests may be failing due to the same issue.

[wearpants]

I specifically need BTRFS/reflink support in my software product, and the proposed ubuntu move to uutils while this basic incompatibility exist is deeply concerning

[sylvestre]

@wearpants why is that "deeply concerning" ?

[wearpants]

@sylvestre I'm not sure what’s unclear about my concern, I have software that depends on cp —reflinks=always and btrfs’s COW behavior

“uutils is a substitute for coreutils oh but actually only the common use cases/configurations” is inherently problematic… either it's a full and faithful re-implementation of coreutils or it is something that looks like coreutils but is dangerously not

There is 50 years of code and millions of systems that depend on coreutils, and by Hyrum’s Law, that includes all of the documented and undocumented behavior