bug-coreutils
[Top][All Lists]
Advanced

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

Re: coreutils-5.2.1: test failure - chgrp/posix-H


From: Michael Deutschmann
Subject: Re: coreutils-5.2.1: test failure - chgrp/posix-H
Date: Thu, 29 Apr 2004 21:49:48 -0700 (PDT)

On Tue, 27 Apr 2004, you wrote:
> Michael Deutschmann <address@hidden> 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 <address@hidden>




reply via email to

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