Sorry for the mess in previous email. Here it is again and clean :)
Just looked at what the server does, it returns E2BIG, I wonder where
that is mapped to the non-descriptive EINVAL error.
It is mapped in srvproc.cc. Lines bellow shows the place:
02871 if (AL_Internalize ((AL_ExternalAccessList) AccessList
->SeqBody, newACL) != 0) {
02872 SLog (0, "CheckSetACLSemantics: ACL internalize
failed (%x.%x.%x)",
02873 Fid .Volume, Fid .Vnode, Fid .Unique);
02874 return(EINVAL);
02875 }
In AL_Internalize, there is a following line:
if (p + m > AL_MaxExtEntries) return(-1);
That is why the execution in case of too big ACL, never gets to the
code right
bellow the previous branch:
02876 if ((*newACL)->MySize + 4 > aCLSize) {
02877 SLog (0, "CheckSetACLSemantics: ACL too big
(%x.%x.%x)",
02878 Fid .Volume , Fid.Vnode, Fid.Unique);
02879 return(E2BIG);
02880 }
02881 }
and EINVAL is returned.
Which is why I think it is probably better to get the correct error code
propagated back from the server to cfs so that it can give a useful
response without having to rely on a hardcoded value.
Jan
I agree. I actually overlooked the second check in srvproc.cc :)
However it is executed only
in case of correct ACL length thus noone sees E2BIG error. Also, my
intention was not let the
cfs to perform the long data path if it is able to detect incorrect
ACL length. But cfs is
not time critical and let the server take care about the return values
is definitely better design.
I can add a function right before AL_Internalize() that just checks
for the length and returns the
E2BIG. The second check can be wiped out.
Later
Jan
