Repository navigation
Remove/deprecate ENOATTR from Linux and Android #1356
Description
Activity
It appears that the header
<attr/xattr.h>, where this constant was supposed to be, was removed in 2015: http://git.savannah.nongnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38The header that one should use is
<sys/xattr.h>which is available on Linux and Android, but does not containENOATTRin either:It appears to be in older copies of the man pages, like https://linux.die.net/man/2/getxattr
(ENOATTR is defined to be a synonym for ENODATA in <attr/xattr.h>.)
In case that gets updated too, here's an archive.org link: https://web.archive.org/web/20160808193900/http://linux.die.net/man/2/getxattr
As per https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html which is also outdated but mostly correct, here's platform behavior:
-
return ENOATTR, while ENODATA is defined and has other usages: NetBSD
and MacOS X -
return ENODATA, while ENOATTR is not defined: Linux
-
return ENOATTR, while ENODATA is not defined: FreeBSD
Notice that if you define ENOATTR as a synonym for ENODATA on Linux with attr/xattr.h as was done previously, then you can use ENOATTR on any platform, which is what I was doing in my code. My code isn't working and hasn't been touched for a while, so you don't need to worry about breaking that.
I think ENOATTR still makes sense for writing cross platform code, but I also agree that it doesn't belong here since Linux seems to have gotten rid of it. I'm not sure if anyone else is using it, it is rather niche, but if we're going to get rid of it we might as well deprecate it first I think.
-
FYI if you need a portable wrapper over
libc, you can use thenixcrate for that. I don't know if they have a portable wrapper around these APIs, but they might.The problem with adding
ENOATTRsynthetically to targets that don't have it is that, technically, Android and Linux could add it in the future, and with a different value ofENODATA. First, we wouldn't know about this, because we are skipping it in our tests. So some people might start to use it, and would be passing these APIs an incorrect value.Second, if we change the value, we'd break old code that uses it as a synonym of
ENODATA(code that on Linux would not compile in the first place), so we'd probably need to deprecate it anyways, and add aENOATTR2that people can use on Linux and Android instead, but now their "cross-platform" code isn't cross-platform anymore.I'm not sure if anyone else is using it, it is rather niche, but if we're going to get rid of it we might as well deprecate it first I think.
This makes sense.
Makes sense. I'm fine with deprecating or removing it. 👍
This constant doesn't exist on Linux, but it does exist on FreeBSD and probably other systems in the BSD clade, and it's actually quite important.
Suppose you want to remove an extended attribute from a file and ignore the error that you get when the attribute doesn't exist. Suppose further that you are using the
xattrcrate. It glosses over the difference in how you do this between OSes:removexattron Linux,extattr_delete_fileon FreeBSD, both wrapped intoxattr::removeby the xattr crate. But it does not gloss over the difference in the error codes; you get a plain oldstd::io::Errorcreated from the raw errno code, which will be ENODATA if you're on Linux and ENOATTR on *BSD. The stdlib does not have error kinds for these codes, and so you're gonna want to write something likexattr::remove("file", "attribute") .or_else(|e| match e.raw_os_error() { Some(code) if code == libc::ENODATA || code == libc::ENOATTR { Ok(()) }, _ => { Err(e) }, })?but this throws deprecation errors on Linux. :-(
Absent any changes to either the stdlib or the xattr crate, how would you write this so it works on both Linux and *BSD and is future-proof?
- added 5 commits that reference this issue
on Aug 11, 2026 - added a commit that references this issue
on Aug 12, 2026 - added 6 commits that reference this issue
on Aug 31, 2026
The
ENOATTRattribute is not shipped with any system headers on these platforms. This was raised in #594 as the main argument not to add this for Linux. There was a comment that claimed that this attribute is mentioned in the man pages ofsetxattrandgetxattrbut I don't find any mention ofENOATTRthere anymore =/Then #1030 came along and added the attribute for Android, but this is not available there either AFAICT, and I can't find it on any documentation.
Go rejected adding
ENOATTRfrom their syscall package for this reason: golang/go#753cc @alexcrichton @mati865 @PlasmaPower