ls NFSv4 is not perfect

[Edward Tomasz Napierała]

Wiadomość napisana przez Andriy Gapon w dniu 1 kwi 2012, o godz. 23:06:
> It seems that aclmode() function in bin/ls/print.c caches ACL support properties
> of a filesystem.  Unfortunately this optimization doesn't always work.
> An example: a UFS directory unionfs-mounted over ZFS directory.  Files that
> reside in ZFS and are not shadowed by UFS do have ACL_NFS4 stuff, files in UFS
> don't have it.
> An example of ls -l behavior in this case:
> -rw-r--r--  1 mrtg  mrtg     3881  1 Apr 06:55 corevoltages-year.png
> -rw-r--r--  1 mrtg  mrtg     5605  1 Apr 06:55 userload-year.png
> -rw-r--r--  1 mrtg  mrtg     2782  1 Apr 06:55 uptime-year.png
> ls: /var/www/stats/mrtg/cpufreq.old: Operation not supported
> -rw-r--r--  1 mrtg  mrtg    61200  1 Apr 23:00 cpufreq.old
> ls: /var/www/stats/mrtg/irqrate.old: Operation not supported
> -rw-r--r--  1 mrtg  mrtg    55538  1 Apr 23:00 irqrate.old
> ls: /var/www/stats/mrtg/cpuload.old: Operation not supported
> -rw-r--r--  1 mrtg  mrtg    58826  1 Apr 23:00 cpuload.old
> ls: /var/www/stats/mrtg/cpuload2.old: Operation not supported
> 
> The older files are in ZFS, the newer are in UFS.
> ktrace, just in case:
> CALL  __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000)
> NAMI  "/var/www/stats/mrtg/uptime.html"
> RET   __acl_get_link 0
> CALL  write(0x1,0x8010be000,0x3b)
> ...
> CALL  __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000)
> NAMI  "/var/www/stats/mrtg/xxx"
> RET   __acl_get_link -1 errno 45 Operation not supported
> 
> Not sure what's the best approach here.
> Maybe just silence this particular error code?

Situation is more complicated than that - there is an optimization
in ls(1) that makes it assume that a given filesystem supports only
one ACL brand, either POSIX.1e or NFS4, and it's determined using
the first file ls(1) will find.  So, in situation above, you'll
get POSIX ACLs for some files and ENOTSUPP for others, _or_ ENOTSUPP
for some files and NFS4 ACLs for others, depending on sorting order.
Same assumption is found in several other tools, such as cp(1).

I think we should leave it as it is - this ENOTSUPP _is_ an error;
silencing it would result in ls(1) indicating different permissions
that are actually being enforced.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?