[1.7] getgroups regression?
Eric Blake
ebb9@byu.net
Fri Dec 4 22:49:00 GMT 2009
Eric Blake <ebb9 <at> byu.net> writes:
>> On the same machine, I see:
>> cygwin-1.5$ id -G | wc
> 1 24 136
>> cygwin-1.7$ id -G | wc
> 1 46 264
> cygwin-1.7$ printf %s\\n `id -G` | sort -u | wc
> 24 24 136
>> In other words, under cygwin 1.7, the last 22 entries are placed in the
> getgroups results twice.
On further review, I found my 1.7 /etc/group was more than twice the size of
the 1.5 version; and all of that bulk came from duplicated entries.
$ ls -l /etc/group.old /etc/group
-rwxr-xr--+ 1 eblake Domain Users 75790 2008年12月15日 10:56 /etc/group.old*
-rwxr-xr-- 1 eblake Domain Users 151559 2009年05月11日 07:51 /etc/group*
$ cmp <(sort -u /etc/group.old) <(sort -u /etc/group); echo $?
0
So, cygwin 1.7 getgroups was listing duplicates because my /etc/group had
duplicates. Remove the duplicates, and now I get the same results in id for
1.7 as I did for 1.5.
But that still makes me wonder - is there anything we are doing in a typical
install that might be accidentally inserting duplicate entries into /etc/group,
or is this something I managed to fubar all by myself way back when I first
created my side-by-side 1.5/1.7 installation (back before the transition was as
smooth as it is now)?
Meanwhile, is sorting and/or pruning duplicate getgroups results something that
cygwin should consider doing? POSIX is explicit that the result is a
mathematical set, and that two processes can have the same set membership but
different orders based on the sequence of events that created those two
processes. But will Linux ever list a duplicate, even if duplicates appear
in /etc/group?
--
Eric Blake
--
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
More information about the Cygwin
mailing list