Re: "ls -l": Avoid unnecessary getxattr() overhead

[Bernhard Voelker]

On 02/17/2012 01:11 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> BTW: I have another question: what if someone has used
>> "./configure --disable-xattr"? ... surprisingly nothing:
>> ls doesn't honor USE_XATTR. Is that correct?
> 
> That option is intended to disable copy.c's attribute-copying code.
> I vaguely recall that initial libxattr implementations had problems.
> It would not be feasible (or sensible, imho) to eliminate all getxattr
> uses from ls.c.

Thanks for the explanation.

> Thanks again for all of the review comments.

Thanks for your patience. ;-)

> Here's the updates series, along with this addition to NEWS:
> 
> ** Improvements
> 
>   ls can be much more efficient, especially with large directories on file
>   systems for which getfilecon-, ACL-check- and XATTR-check-induced syscalls
>   fail with ENOTSUP or similar.

Do you think it's worth to distinguish between ENOTSUP and EOPNOTSUPP?

I.e. on system returning EOPNOTSUPP, when the files reside on N different
filesystems (or when processed in an unlucky order), then ls would still
try to get these attributes although we already know that the system does
not support it.

If so, then besides another flag, this would mean to s/ENOTSUP/EOPNOTSUPP/
here:

> diff --git a/src/ls.c b/src/ls.c
> index 8a9cb41..92b17a4 100644
> --- a/src/ls.c
> +++ b/src/ls.c
> @@ -2736,6 +2736,7 @@ has_capability (char const *name)
>  static bool
>  has_capability (char const *name ATTRIBUTE_UNUSED)
>  {
> +  errno = ENOTSUP;
>    return false;
>  }
>  #endif

Have a nice day,
Berny