IOException from sun.nio.fs.UnixUserPrincipals.lookupName

Jonathan Lu luchsh at linux.vnet.ibm.com
Mon Nov 21 01:50:07 PST 2011


On 11/21/2011 04:34 PM, Alan Bateman wrote:
> On 21/11/2011 07:35, Jonathan Lu wrote:
>>
>> Since these checks are all about the result of getpwnam_r API, so I 
>> searched the system manual and found,
>> The Linux manual says,
>> ERRORS
>>        0 or ENOENT or ESRCH or EBADF or EPERM or ...
>>               The given name or uid was not found.
>>
> If you skip down to the Notes section of the man page then it reads:
>
> " The formulation given above under "RETURN VALUE" is from 
> POSIX.1-2001. It does not call "not found" an error, and hence does 
> not specify what value /errno/ might have in this situation. But that 
> makes it impossible to recognize errors. One might argue that 
> according to POSIX /errno/ should be left unchanged if an entry is not 
> found. Experiments on various UNIX-like systems show that lots of 
> different values occur in this situation: 0, ENOENT, EBADF, ESRCH, 
> EWOULDBLOCK, EPERM and probably others"
>
> so it is hard to distinguish the "not found" case. In our experiments 
> on Linux and Solaris with different name services (NIS, LDAP) then the 
> current code handles all cases. So are you seeing this on AIX or have 
> you seen it elsewhere? I'm just curious and don't have any objection 
> to extending the errors that map to not found. I'm also curious if 
> getgrnam0 has the same issue.
Yes, this problem was originally found on AIX platform and I just tested 
getgrnam_r(), it failed with the same errno as getpwnam_r(), so I think 
if there's an adjustment, getgrnam0 should be included too.

>
> -Alan.

- Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111121/bb75a02a/attachment.html 


More information about the nio-dev mailing list