[folbricht]

Extracting an archive carrying extended attributes did one of three things depending on where it ran:

platform	untar of an archive with xattrs
Linux, macOS, FreeBSD	applies them
NetBSD, on a filesystem without extattr	fails
OpenBSD, DragonFly	reports success and writes nothing

The third row is the problem. pkg/xattr compiles in stubs that return nil on those platforms, so files end up missing what the archive said they should have, with a zero exit code. It is the same shape as the device-number bug fixed in #405: doing something other than what the archive asked for, quietly.

The change

Refuse rather than pretend, which collapses the three cases into one consistent behaviour, and add --no-same-xattrs so a caller can decline the attributes deliberately.

The flag fills a gap in the existing set — every other class of metadata could already be opted out of:

metadata	opt-out
ownership	--no-same-owner
permissions	--no-same-permissions
extended attributes	--no-same-xattrs (new)

untar only. tar has no owner or permission flags to match, and its --no-time exists to stop timestamps churning chunks between runs rather than as a metadata opt-out, so there is nothing on that side to be symmetric with.

Beyond the BSDs this covers extracting onto any filesystem without xattr support — vfat, or a restricted container build.

Two paths to the same outcome

Failure arrives by one of two routes, and both now say the same kind of thing:

situation	message
platform has no xattr support (OpenBSD, DragonFly)	f: extended attributes are not supported on this platform
platform supports them, this filesystem does not (vfat, tmpfs on NetBSD)	f: extended attributes are not supported by this filesystem: ...

The second route already failed before this change — setXattrs has always propagated that error — but it surfaced as a bare xattr.FSet /mnt/f user.test: operation not supported, naming neither the attributes as the cause nor the fact that they can be skipped. It is also the case most people will meet, since it covers Linux. The errno stays wrapped, so callers can still test for it, and every other failure keeps its own wording.

Three cases still succeed, by design: an archive that carries no attributes (the common one, so ordinary archives still extract onto vfat), --no-same-owner (see below), and Windows.

Measured against a vfat loop image rather than reasoned about:

invocation	before	after
default	xattr.FSet ...: operation not supported	extended attributes are not supported by this filesystem: ...
--no-same-xattrs	n/a	succeeds
--no-same-owner	succeeds	succeeds
archive without xattrs	succeeds	succeeds

Noted, not changed

--no-same-owner already skips extended attributes as a side effect: all four call sites sit inside if !fs.opts.NoSameOwner. That looks deliberate, since both need privileges, but it does mean --no-same-owner has been a partial xattr opt-out all along. Changing it is a separate decision and is left alone here.

Windows never applied extended attributes, so the flag is accepted and ignored there, as --no-same-owner and --no-same-permissions already are.

Tests

TestSkipXattrs covers the decision the two setters share, with no actual xattr call — whether one succeeds depends on the filesystem under the test's temp dir, which differs across the CI matrix, so asserting on real attributes would be flaky. It asserts the refusal on platforms where xattr.XATTR_SUPPORTED is false, which is what the OpenBSD and DragonFly VM jobs exercise.

TestXattrWriteError covers the rewording, including that an unrelated failure such as EACCES is left alone and that the errno stays wrapped.

TestCreateFileNoSameXattrs threads the flag through CreateFile end to end. The node is owned by the caller so the chown alongside the xattrs succeeds without root, and NoSameOwner is deliberately left off, since turning it on would skip the setters entirely and test nothing.

Platform table and generated CLI reference updated.