[Tux3] Extended attributes have landed in tux3.c

[Maciej Żenczykowski]

man setxattr: If extended attributes are not supported by the
filesystem, or are disabled, errno is set to ENOTSUP.

On Thu, Sep 11, 2008 at 21:56, Tero Roponen <tero.roponen at gmail.com> wrote:
>
> On Thu, 11 Sep 2008, Daniel Phillips wrote:
>
>> So it seems we have a new build dependency: libattr1-dev.  And we have
>> a way of compiling without it, the only bad effect of which is to return
>> ENOENT instead of ENOATTR, which does not seem like such a bad thing
>> considering you return EEXIST in your fuse patch, which wrongly implies
>> that the offending object is a file, just as ENOENT does.
>
> Well, the man-page of setxattr has this information:
>
>        If XATTR_CREATE is specified, and the attribute exists already,
>        errno is set to EEXIST.  If XATTR_REPLACE is specified, and the
>        attribute does not exist, errno is set to ENOATTR.
>
> and attr/xattr.h has this:
>
> #ifndef ENOATTR
> # define ENOATTR ENODATA        /* No such attribute */
> #endif
>
> So just replacing ENOATTR with ENODATA should be fine.
>
>
>
>
>>
>> Of course we can handle this nicely with pkg-config, right?  Well,
>>
>>    pkg-config --cflags libattr1
>>    Package libattr1 was not found in the pkg-config search path.
>>    Perhaps you should add the directory containing `libattr1.pc'
>>    to the PKG_CONFIG_PATH environment variable
>>    No package 'libattr1' found
>>
>> Bummer.  Upstream for this package... or is it the package maintainer...
>> does not know or care about pkg-config.  Also, upstream for sys headers
>> does know know or care about xattrs, or my headers are out of date
>> which is a distinct possibility.
>>
>> Anybody have suggestions on how to tidy this up, including where to send
>> patches upstream?
>>
>> Until we have at least a pkg-config type solution I think we are better
>> off returning a slightly wrong error code than adding another build
>> dependency, thus steepening the pain curve for new Tux3 members
>> compiling for the first time.  I could be wrong about that, maybe we are
>> nowhere close to the pain threshold for dependencies yet.
>>
>> Regards,
>>
>> Daniel
>>
>
> _______________________________________________
> Tux3 mailing list
> Tux3 at tux3.org
> http://tux3.org/cgi-bin/mailman/listinfo/tux3
>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3