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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=FQLSq46W5SQTbmk/T+6M1e+Gy71pkzvdmXPfmzgLwSk
	MWNTFvIXS/HN+c1ndCmTvNTqJ0O5JxLAkfQg+ku9uTNlrzOW+5kATdj4xXzuUhpt
	p5Cw4uJGZZsgkgrORODxjR2EfnmzsEiOHgoT5vTFcseoleLfmBN0/g3RmEChJDME
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=MUOVenwLz2q/M3KrX7wzbrApEwg=; b=uQ3PwY6ujpvBOCAHy
	G1Rqok/nM+kFDRdT48hzcry5q/rapP5P1WSOSxwJQdDCzeMXW7lzBKBEcl4i7oDc
	uSZQAbpuEFR4vvl/7o6RcT26vQeXT74qLg9WhbPRgt6RWz1M4+ebSH+YFlbfX/7R
	pPW0JHV6ukQWqJcd78jm2UtdU0=
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-Spam-SWARE-Status:	No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	etr-usa.com
Message-ID:	<52F40208.5030901@etr-usa.com>
Date:	Thu, 06 Feb 2014 14:43:36 -0700
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
References:	<52F339CA DOT 5070305 AT gmail DOT com> <20140206090117 DOT GD2821 AT calimero DOT vinschen DOT de> <52F361C5 DOT 3000807 AT gmail DOT com> <20140206141321 DOT GI2821 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20140206141321.GI2821@calimero.vinschen.de>
X-IsSubscribed:	yes

On 2/6/2014 07:13, Corinna Vinschen wrote:
>
> Btw., it would be a good idea to get rid of calls to getpwent/getgrent
> in future.  They *probably* won't do anymore what they were supposed to
> do if you don't have passwd/group files.

There must be a way to list an executable's DLL imports, and thereby do 
a survey on Cygwin to see which executables currently import those 
functions.  If so, I know a guy who currently has all of Cygwin 
downloaded and ready to re-install, to test this. :)

I tried futzing with objdump, nm, and dumpbin, and couldn't get anything 
useful.  Mainly what I got was either irrelevant or complaints of the 
"no string table" sort.

 > A full implementation would
> require to enumerate the local SAM and, at least, the primary domain
> accounts at runtime.  That would be possible, but it comes at a hefty
> price in terms of performance.

Linux and Cygwin are pretty much the last ones standing when it comes to 
preferentially reading plain text files in /etc for user info.  Big iron 
Unix, the BSDs, and Mac OS X now all treat these files as secondary to 
some behind-the-scenes database.

In some of these systems, you can edit /etc/foo and run a command to 
manually sync that content back to the "real" user info DB.  (e.g. the 
BSDs)  In others, direct edits to these files are ignored, but the OS 
syncs a subset of changes to the user info DB to these files, for the 
benefit of getpwent() and friends.  (e.g. Mac OS X.)

In Cygwin, we have a kind of hybrid of these, owing to the fact that the 
integration between Cygwin and Windows is pretty much one-way.  We have 
mkpasswd/group, which treats the DB as primary, like OS X, but which 
must be run manually to sync changes, like the BSDs.

I don't see a reason for this to change, given that so many other POSIX 
systems share aspects of this behavior.

It would be nicer if Cygwin behaved more like OS X in this regard. 
That is, for mkpasswd/group to be run automatically when the SAM/AD 
changes.  I don't see Microsoft doing that for us, though.

The only way I can think of for Cygwin to do that for itself would be to 
run mkpasswd/group from setup.exe, in the same way that it runs 
autorebase.

I realize the current recommended practice is to keep /etc/foo as small 
as possible, but shouldn't an AD/SAM DB lookup be faster than a linear 
scan of a large /etc/foo file?  Why lament the fact that getpwent() is 
slow, when getpwnam() is its logical replacement, and presumably much 
faster?

(I assume getpwnam() consults SAM/AD in Cygwin, now or in Cygwin.next.)

Here's the Mac OS X passwd(5) man page: http://goo.gl/AwIHku

It's relevant here because Mac OS X uses OpenDirectory, an LDAP 
directory server.  In that way, it is not unlike future-Cygwin+AD.

--
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 -