tests: make xattr test more robust

[bertschingert]

Currently the xattr test asserts that listxattr() on Cargo.toml returns a length of 0.

This causes a spurious failure when Cargo.toml does have xattrs, and this can happen in fairly normal situations like when a Linux distribution enables selinux (as it does on an AlmaLinux 10 test system, for example):

$ cat /etc/almalinux-release
AlmaLinux release 10.0 (Purple Lion)

$ getfattr -d -m - Cargo.toml
security.selinux=[...]

$ cargo test --features=fs,stdio xattr
[...]
thread 'xattr::xattr_basic' panicked at tests/fs/xattr.rs:88:5: assertion left == right failed
left: 17
right: 0

This change fixes the failure by making the test not assume that the file has no xattrs defined.

Given that, pretty much the only reasonable thing the test can assume about a call to listxattr is that it should succeed for a file that is known to exist. So this makes the test just assert that it succeeds.

---

Aside from how the above commit fixes this test, there are other methods that could be better:

• Run filesystem tests in a sandbox environment where the filesystem is under complete control of the rustix test suite and there is no unexpected state that can cause spurious failures
• Compare the listxattr() output with the output of an external implementation and assert that they are equal. For example, launch a "getfattr" binary command and parse its output

Thoughts on either of those approaches? They would be more complicated but could offer better coverage.

[sunfishcode]

Another option for xattr tests would be to have tests use the libc crate API directly, and then compare that with the results from using the rustix API. That seems simpler than setting up a filesystem sandbox or parsing the output of a shell command. That said, I'm happy to go with whatever you think is best.

[bertschingert]

Using the libc crate makes sense to me -- the latest version does it that way.

[sunfishcode]

Thanks!