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

[anirkko]

> 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.

> > Also, in tests/rm/no-give-up, wouldn't 'chmod 755 .' (or equivalent) be 
> > better
> > than 'chmod go= .' in the sense that the test should always test exactly
> > the same thing, independent of umask? (i.e. the u bits also guaranteed 
> > always
> > the same, in case umask was something stupid with nonzero u) Or else, maybe
> > explicitly set umask?
> 
> Thanks for looking into that.
> I've fixed it by adding the "chmod go=x .", below.
> 
What I meant was that theoratically, it should also be able to cope also
with unreasonable umasks like 700 or 721 etc, so the full permissions for
_all_ u, g and o bits (including u) should be set to a defined state in every
circumstance. If you don't like "755", then "u=rwx,go=rx" would be equivalent?

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.

Greets,
Arto