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