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