Hi Stephen, On Sun, May 27, 2007 at 03:01:48PM +0100, Stephen Gran wrote: [..snip..] > And this is the output: > > gid_t: 10110 starting > gid_t: 10110 done > gid_t: 10800 starting > Enlarging buffer from 496 to 992 > gid_t: 11197 starting > gid_t: 11197 done > > Note that gid 10800 (the giant group) never shows done. Yes there's a bug here, but I can't reproduce it (as you saw from my output). Just to be sure I checked etch and it works there too. What backend are you using? Maybe the bug is lurking there? Maybe the backend isn't returning ERANGE as it should?
[..snip..] > > /* The status is NSS_STATUS_TRYAGAIN and errno is ERANGE the > > provided buffer is too small. In this case we should give > > the user the possibility to enlarge the buffer and we should > > not simply go on with the next service (even if the TRYAGAIN > > action tells us so). */ > > I saw that, and what it says to me is that the only way to do this is to > rewind to the top of the loop and try again with a larger buffer. > Currently, the buffer is being resized for all subsequent getent calls, > but not for the failed one. Hmm...I interpreted this (and the code) like: "in this case we _will_ give the user the possibility ..." - isn't this why the loop breaks and returns the NSS_TRY_AGAIN? Note the __nss_next isn't called in this case. I'm quiet sure the backend is at fault, could you try to deliver the "giant" group via the file backend? I'm quiet sure this works and in this case this bug should be reassigned to libnss-<your-backend> - probably ldap. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
