On Fri, Sep 9, 2016 at 2:18 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> Okay, so how do we do this correctly? The desired end result is
> clear: FOOBAR xattr doesn't exist on the directory. This "doesn't
> exist" is a negative result, so the only way to check it is to check
> for errors. Either with removexattr() or getxattr() this will get us
> into the same trap: that there are multiple errors that have this
> meaning.
>
> Same thing with ENOENT: checking for non-existence can be difficult,
> because ENAMETOOLONG is actually a special form of ENOENT.
Yeah, ENOENT, ENAMETOOLONG, ERANGE, EINVAL can all be different
versions of "this doesn't exist" - perhaps because such a name
*cannot* exist on the filesystem.
> I just don't see the "right" soltion here, and while I agree that the
> current one is ugly, it should actually work. We won't get ERANGE,
> because the posix acl xattrs have short names that'll fit in all
> filesystems and 9p isn't even a valid fs for the upper layer of an
> overlay.
So maybe the right thing to do is to just document it, and have a
comment that shows that the code at least knows about these things and
that it doesn't matter in practice.
The "just check for two errors without any comments about why those
particular two errors are different from all the *other* errors" is
what I really objected to.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
