Re: umask also influences test/rm/fail-2eperm

[Jim Meyering]

address@hidden wrote:
>> From address@hidden Fri May  4 12:04:56 2007
> ...
>> address@hidden wrote:
>> > coreutils-6.9/tests/rm/fail-2eperm needs a 'chmod 644 a/b' or equivalent
>> > after the 'touch a/b || framework_failure=1' to be able to cope with
>> > different umasks.
>> > No idea though why it had shown up sometimes, not othertimes, with the 
>> > same umask=000.
>>
>> Since I am unable to reproduce that, I'm reluctant to change anything
>> without understanding the problem.  Can you provide more detail?
>
> When looking at the test, I can understand why 'chmod 644 a/b' should
> be called so that the test can cope with different umasks. What I don't
> understand yet is why umask doesn't propagate to this test, depending on
> what happeded before. But does it matter? The test should probably work
> with any umask, so all u,g, and o bits should be set to a predefined
> state and not left to random influences. I guess you should be able
> to reproduce the problem it if you put 'umask 000' at the beginning,
> into the test itself.

Oh!  I made the same mistake.
To reproduce *that* failure you need to specify an unusable umask.
E.g., one that prohibits any of the owner rwx bits:

    umask 777

Sure, I could work around such silliness by simply adding this
near the beginning:

    # Protect against a ridiculously restrictive umask.
    umask 077

However, I'm not sure it's worthwhile, since no one would use a umask
prohibiting any of u=rwx for long.  And a similar change would be
required for most other tests.

If you can make it fail with a umask affecting only group/other
bits, then please let me know.

> Also, the problem in tests/ls/color-dtype-dir turns out to be related
> to umask, too: for the same reason as in the above two tests (defined state
> of all bits), the two lines
>   chmod o+w other-writable || framework_failure=1
>   chmod o+t sticky || framework_failure=1
> can be replaced by
>   chmod 757 other-writable || framework_failure=1
>   chmod 1755 sticky || framework_failure=1
> (or equivalent symbolic versions of 757 and 1755) and then that (non-root 
> test)
> also passes.

Thanks for pointing that out.
For the record, I can reproduce the failure with this umask, among others:

    $ (umask 1; make -C ls check TESTS=color-dtype-dir)
    make: Entering directory `/f/w/cu/tests/ls'
    make  check-TESTS
    make[1]: Entering directory `/f/w/cu/tests/ls'
    out exp differ: char 9, line 1
    1c1
    < ^[[0m^[[34;42md^[[0m$
    ---
    > ^[[0m^[[01;34md^[[0m$
    4c4
    < ^[[30;42msticky^[[0m$
    ---
    > ^[[37;44msticky^[[0m$
    FAIL: color-dtype-dir

I fixed it like this:

        Avoid test failure when run with an unusual umask.
        * tests/ls/color-dtype-dir: Set umask to 022.
        Suggestion from AIDA Shinra.

diff --git a/tests/ls/color-dtype-dir b/tests/ls/color-dtype-dir
index f3f9ee9..41c8bf3 100755
--- a/tests/ls/color-dtype-dir
+++ b/tests/ls/color-dtype-dir
@@ -4,7 +4,7 @@
 # directories the same as the first one -- but only on a file system
 # with dirent.d_type support.

-# Copyright (C) 2006 Free Software Foundation, Inc.
+# Copyright (C) 2006-2007 Free Software Foundation, Inc.

 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -33,6 +33,9 @@ t0=`echo "$0"|sed 's,.*/,,'`.tmp; tmp=$t0/$$
 trap 'status=$?; cd "$pwd" && chmod -R u+rwx $t0 && rm -rf $t0 && exit 
$status' 0
 trap '(exit $?); exit $?' 1 2 13 15

+# Don't let a different umask perturb the results.
+umask 22
+
 framework_failure=0
 mkdir -p $tmp || framework_failure=1
 cd $tmp || framework_failure=1