This is the mail archive of the
mailing list for the Cygwin project.
Re: [1.7] getgroups regression?
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Fri, 4 Dec 2009 22:48:35 +0000 (UTC)
- Subject: Re: [1.7] getgroups regression?
- References: <loom.20091204T232305firstname.lastname@example.org>
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 $?
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple