delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2014/02/12/16:37:54

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; q=dns; s=
default; b=A+oysq2YFdwvmbGMnzCssdMMgIGe7F/soh7tJKl5u7RUXiny83A24
S/1yISQoyRfIF5vOPVMOpyNvkUJGTkYaV/qwmZWkrtyJbix1qVdnLwEYWjfKMz8D
FLZdxI9CHe63xAwUP/ILiEfwD1U4qYpJvVoD0UtaBriFD/aWEIUJyA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; s=default;
bh=ywCM5i996F0n7PBiGhQDkPHobbE=; b=sMzpqOSdz44logPrkSXizf4e9RoW
yUzJVRBPTGWP6pj7PfnFQbaIhah8vODc5jvuDPEAYJ8lLXkHLlY2y1dx4CGAfs+9
pYHfNQyfm/9KzW7MSqRTGRthW23duIRZftlDgTz8N/dMGKuAUgOm7LmVnIysJthd
JFQ5o5W5vOF4DJE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: mho-01-ewr.mailhop.org
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Report-Abuse-To: abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19rWkE+1ArlnudiCE1g+DLR
Date: Wed, 12 Feb 2014 16:37:29 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
Message-ID: <20140212213729.GA5589@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <52F8B50E DOT 7040307 AT lysator DOT liu DOT se> <52F92D58 DOT 9030408 AT etr-usa DOT com> <52F95D1D DOT 4050108 AT tiscali DOT co DOT uk> <4510121021 DOT 20140211062515 AT mtu-net DOT ru> <52FAB14C DOT 8060800 AT tiscali DOT co DOT uk> <52FABAF5 DOT 2060701 AT etr-usa DOT com> <52FAD730 DOT 9090507 AT redhat DOT com> <20140212090804 DOT GM2821 AT calimero DOT vinschen DOT de> <52FB9E51 DOT 7030607 AT cornell DOT edu> <20140212195931 DOT GA2246 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
In-Reply-To: <20140212195931.GA2246@calimero.vinschen.de>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
>On Feb 12 11:16, Ken Brown wrote:
>> On 2/12/2014 4:08 AM, Corinna Vinschen wrote:
>> >On Feb 11 19:06, Eric Blake wrote:
>> >>On 02/11/2014 05:06 PM, Warren Young wrote:
>> >>>On 2/11/2014 16:25, David Stacey wrote:
>> >>>>getpwent() is called in three different places.
>> >>>
>> >>>To those of you who have investigated these code paths: do any of them
>> >>>look like they couldn't be replaced by getpwnam() or other calls that
>> >>>would let cygwin1.dll do single-record AD/SAM lookups, rather than
>> >>>whole-table/tree scans?
>> >>>
>> >>>That is, do any of these programs really need to visit every record in
>> >>>/etc/passwd?
>> >>
>> >>libreadline wants to know how to tab-complete ~foo; to do that, it has
>> >>to find all usernames beginning with foo.  How would you do that without
>> >>visiting every single record?
>> >
>> >This seems to be the major usage of getpwent these days.  The question
>> >is, how bad is it if only a handful entries, or even only a single one
>> >(of oneself) show up?
>> >
>> >Either way, implementing a full getpwent requires to return the local
>> >users, the users of the primary domain, and the users of all trusted
>> >domains.  I know of domains with 200K users and there are probably
>> >bigger ones.  How long should a search take when a user presses <TAB>
>> >after the ~?  And then, shall the process running the getpwent actually
>> >cache all of them?  This seems really excessive.
>> 
>> What about the following compromise:  If /etc/passwd exists, then
>> getpwent behaves as it does currently.
>
>This part is relatively easy to implement.
>
>> Otherwise, it returns a
>> handful of entries, or possibly just the current user.
>
>The handful entries would be the ones the process has cached at that
>point in time.  The tricky part is that getpwent would have to keep
>track which entries from the file are in the cache so that those are not
>accidentally enumerated twice.
>
>> This gives
>> users a choice.  If tab-completion in this situation is important to
>> them, they can keep their /etc/passwd file.
>
>There's only one tiny problem.  Whatever I think about the full
>enumerate being right or wrong, I have this vague feeling that I'd like
>to have this implemented fully at one point.  My cat disapproves, but we
>can't agree on everything, I guess.  Another configuration option in
>/etc/nsswitch.conf might comfort her.

I don't know if this has been mentioned but would a cache help here,
i.e., nscd?  I think that's how Linux deals with this type of situation.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019