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
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT 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>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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