ACL problem with NFSv4 and DELETE_ACCESS
Jiri Sasek - RPE Prague
Jiri.Sasek at Sun.COM
Tue Jun 24 11:23:45 GMT 2008
Nicolas Dorfsman wrote:
> Hi Volker,
> Le 18 juin 08 à 11:52, Volker Lendecke a écrit :
>> Just found in the SUN docs of the acl(2) system call that is
>> evolving or uncommitted. This is really brillant, because
>> according to their docs it means:
>>> No commitment is made about either source or binary
>>> compatibility of these interfaces from one Minor release to
>>> the next. Even the drastic incompatible change of removal of
>>> the interface in a Minor release is possible.
>> Can we use this AT ALL?
> man -s5 attributes extract :
> An Evolving interface may eventually become Standard or
> Stable but is still in transition.
> Sun will make reasonable efforts to ensure compatibility
> with previous releases as it evolves. When non-upwards
> compatible changes become necessary, they will occur in
> minor and major releases; such changes will be avoided
> in micro releases whenever possible. If such a change is
> necessary, it will be documented in the release notes
> for the affected release, and when feasible, Sun will
> provide migration aids for binary compatibility and con-
> tinued source development.
> Are you still afraid ?
"Evolving" really mens the interface is uncommitted and can be changed
by Sun but in case of the acl(2) you should have on your mind the ace_t
structure is using layout of the "NFSv4 wire format" for the flags so
the RFC 3530 should be rewritten first in this case. Also the ZFS is
using the NFSv4 extended ACL interface so here is a lot of code in
Solaris which should be rewritten in such case :-)
More information about the samba-technical