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