[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

AltStyle によって変換されたページ (->オリジナル) /