bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 4 test failures on freebsd8-rc2


From: Eric Blake
Subject: Re: 4 test failures on freebsd8-rc2
Date: Thu, 12 Nov 2009 19:24:44 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Jim Meyering <jim <at> meyering.net> writes:

> > chown will be harder, since there is no test-chown already written to
> > start from.  I'm starting to think I will have to use getgroups to see
> > whether the current user has a supplementary group membership, since
> > that's about the only observable successful change that can be made to
> > pinpoint whether the right file was modified.  But that means the test
> > will be reduced, or even skipped, if the user only belongs to one group.
> 
> For this reason, when possible on test systems, I give myself
> membership in a second group.

I thought of one other possible way to see if chown works on the right file; 
but I'm not sure how portable it is.  Per POSIX, calling chown is not called 
with both arguments of -1, then ctime must be updated (the portability problem 
is determining whether all kernels obey that rule, or if some of them 
mistakenly optimize away the ctime change if you aren't changing the 
owner/group but didn't use -1).  Therefore, even with membership in only one 
group, it would be possible to use [u]sleep between events to see which file 
gets updated (using the same algorithm as in test-stat-time for determining an 
ideal usleep time; 20 ms on decent filesystems, up to 2 seconds otherwise).

Given that sleeps can get painfully long, the sleep solution should only be 
tried in the one-group scenario.  Which means the test will be rather hairy to 
write.

> > And then there's mingw to worry about, with neither getgroups nor chown.
> > Also, the gnulib implementation of getgroups can call exit(), so I'd like
> > to fix that first.
> 
> coreutils' mgetgroups does that.
> I guess it's time to move that module into gnulib.

See my other threads on this.

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]