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 <cid:[EMAIL PROTECTED]>((AL_ExternalAccessList <cid:[EMAIL PROTECTED]>) AccessList <cid:[EMAIL PROTECTED]>->SeqBody, newACL) != 0) { 02872 SLog <cid:[EMAIL PROTECTED]>(0, "CheckSetACLSemantics: ACL internalize failed (%x.%x.%x)", 02873 Fid <cid:[EMAIL PROTECTED]>.Volume <cid:[EMAIL PROTECTED]>, Fid <cid:[EMAIL PROTECTED]>.Vnode <cid:[EMAIL PROTECTED]>, Fid <cid:[EMAIL PROTECTED]>.Unique <cid:[EMAIL PROTECTED]>); 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 <cid:[EMAIL PROTECTED]>(0, "CheckSetACLSemantics: ACL too big (%x.%x.%x)", 02878 Fid <cid:[EMAIL PROTECTED]>.Volume <cid:[EMAIL PROTECTED]>, Fid <cid:[EMAIL PROTECTED]>.Vnode <cid:[EMAIL PROTECTED]>, Fid <cid:[EMAIL PROTECTED]>.Unique <cid:[EMAIL PROTECTED]>); 02879 return(E2BIG); 02880 } 02881 }
and EINVAL is returned.
I agree. I actually overlooked the second check in srvproc.cc :) However it is executed onlyWhich 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
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 <cid:[EMAIL PROTECTED]>() that just checks for the length and returns the
E2BIG. The second check can be wiped out.
Later
Jan