[wontfix] cp: ignore unsupported xattr errors on platforms without xattr support

[krosci]

On platforms without extended attribute support such as OpenBSD, the xattr crate returns io::ErrorKind::Unsupported and BSD systems use distinct errno codes. The optional attribute preservation check in cp and uucore now recognizes io::ErrorKind::Unsupported along with ENOTSUP, EOPNOTSUPP, and ENOSYS to match GNU behavior. This prevents cp -a and --preserve=all from failing with spurious error diagnostics on unsupported platforms.

[xtqqczze]

The underlying issue is addressed in a more robust way in #14652.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tail/F-vs-rename. tests/tail/F-vs-rename is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)

[xtqqczze]

@krosci Thanks, but I prefer to exclude OpenBSD at compile time, this PR will be closed by #14652, unless you disagree?

[krosci]

@xtqqczze I think excluding it at compile time might introduce some technical debt. Here is why: Ruling out an entire operating system outright during compilation is too rigid an approach. The problem isn’t OpenBSD itself, but the lack of a specific feature. If OpenBSD were to add support for extended attributes in the future, or if another system had the same limitation, a hardcoded block at compile-time would force us to revisit the code to update the exceptions. Handling the error at runtime, on the other hand, is the more robust approach and is in line with the philosophy of classic Unix tools: the program attempts to perform the operation, and if the OS responds with “not supported,” it handles the situation cleanly and moves on. Filling the code with conditional flags to disable parts of the program based on the operating system’s name is merely a shortcut that creates technical debt; not a true architectural solution.

[xtqqczze]

@krosci The issue is that OpenBSD is not supported by the xattr crate, so even if OpenBSD added support for extended attributes in the future, the operation would never succeed. If the xattr crate were to implement OpenBSD support, then I would agree with your approach. This is tracked by Stebalien/xattr#121.

See also: #14642

[krosci]

That's fair context, and I see where you're coming from regarding the current limitations of the xattr crate.

​However, from an architectural standpoint, this is still a workaround that conflates an upstream dependency limitation with our own design decisions.
​Tying our compilation logic to an OS name rather than feature capabilities is precisely what accumulates technical debt. Even if xattr doesn't currently support OpenBSD, the ideal design on our side would be to encapsulate or stub the xattr call so that our core logic remains agnostic, handling failure (or an unsupported feature state) gracefully at runtime or behind a clean abstraction layer.
​Relying on a hardcoded compile-time exclusion for an entire OS is a shortcut that temporarily masks an upstream gap at the expense of our codebase's long-term cleanliness and maintainability.

[xtqqczze]

Just to clarify, with xattr's unsupported feature enabled (as it is now), the crate doesn't attempt the operation on OpenBSD; it unconditionally returns io::ErrorKind::Unsupported from Rust code: https://github.com/Stebalien/xattr/blob/master/src/sys/unsupported.rs

[krosci]

Yes, exactly! That's precisely the behavior we want. Having the crate unconditionally return io::ErrorKind::Unsupported is perfect: it ensures the build doesn't break on OpenBSD and allows us to handle the missing feature cleanly and predictably in the calling code, all while keeping the API consistent

[xtqqczze]

Sorry, but it can be a pain to track down the cause of failures when things can fail at runtime instead of compile time. See #14640, #14642, #14647 for some context on how much trouble this has caused us.

[krosci]

I completely understand the frustration with runtime failures, and looking at those past issues, it makes sense why you'd want to catch things at compile-time, but returning io::ErrorKind::Unsupported is fundamentally different from a silent failure or an unexpected runtime panic. By doing this, we are actually following the Rust standard library precedent, just like std::os::unix::fs::chown handles unsupported platform features by returning an unsupported error rather than breaking the build. Because the operation returns a Result, we aren't introducing an unhandled exception; the caller is forced by the compiler to acknowledge the outcome and can easily match against ErrorKind::Unsupported to implement a clean fallback, like logging a skip message instead of crashing. Most importantly, forcing a compile-time failure has a massive blast radius: if xattr fails to compile, every downstream crate in the dependency tree instantly fails to build on OpenBSD, even if extended attributes are just a minor, optional feature for their specific use case. By returning a well-typed runtime error instead, we allow the broader ecosystem to actually compile on OpenBSD, leaving the final decision to the downstream application on whether to gracefully ignore the missing feature or handle the lack of support safely

[oech3]

+1 for build time error. There is no benefit to include gabage to binaries.

[xtqqczze]

Upon further investigation, OpenBSD does not support extended file attributes, and there is no corresponding API for xattr to implement. As a result, I closed the upstream issue: Stebalien/xattr#121.

[oech3]

OK. Then we can close this PR and just guard building it.