(Illustration by Gaich Muramatsu)
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 > > JanReceived on 2005-04-16 05:23:22