On Tue, 27 Apr 2004, you wrote:
> Michael Deutschmann <[EMAIL PROTECTED]> wrote:
> > The failing test is "chgrp/posix-H". This test does not give any useful
> > output. However, experiments with a modified test script (with added echo
> > statements) show that the problem is with the test file "1", in the first
> > "for" loop of the test. The test expects it's group to have changed to
> > "$g2", but it has not.
> >
> > Vitals:
> > i486-pc-linux-gnu
> > Linux 2.0.40
> > GCC 2.95.3
> > GLIBC 2.1.3
>
> linux-2.0.40 must have parts that are pretty old, and not as
> standards-compliant. I suspect that is the problem.
> With linux-2.2 through 2.6, I know of no test failures.
Actually, it's just that linux-2.0.40 has only one chown syscall, which
has always (on i386) had "lchown()" semantics. It looks like the glibc
developers have, ( uncharacteristically :) ) opted against bloat and
decided to use that syscall as a direct replacement for regular chown(),
instead of emulating it using readlink.
I patched 2.0.40 to implement the second non-lchown() chown syscall into
2.0.40, and all tests pass under the modified kernel.
So it looks like there are three paths out:
1. Declare that it's okay for chgrp -H to change the link ownership only
(whether this option is available depends on what the standards say.)
2. Get my kernel mod adopted into 2.0.41, then define Linux >= 2.0.41 as
a coreutils prerequisite.
3. Alter coreutils to defend against the possibility that chown() is
really lchown().
#2 looks promising, however if other OSes have this `bug' #3 would be
better.
---- Michael Deutschmann <[EMAIL PROTECTED]>
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
