> From [EMAIL PROTECTED] Fri May 4 12:04:56 2007 ... > [EMAIL PROTECTED] 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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
