[Python-Dev] Strange umask(?)/st_mode issue
That does sound strange. How easily can you reproduce it? That majorly
effects how I would try to debug something like this...
If you're able to get an strace of a failed run then that would probably
tell us a *lot*.
On Fri, Mar 29, 2019, 16:28 Steve Dower <steve.dower at python.org> wrote:
> I'm trying to track down the cause of the failed Linux tests on this
> build (it's also been happening on random PR builds for the last day or
> two, but this is the first I've seen it happen on already merged code):
> One of the failed tests is this one from test_tarfile.py (and I think
> this is representative of the others):
> def test_file_mode(self):
> # Test for issue #8464: Create files with correct
> # permissions.
> if os.path.exists(tmpname):
> original_umask = os.umask(0o022)
> tar = tarfile.open(tmpname, self.mode)
> mode = os.stat(tmpname).st_mode & 0o777
> self.assertEqual(mode, 0o644, "wrong file permissions")
> It's failing because the mode of the new TAR file is 0o666 rather than
> 0o644. I'd guess that this means the umask() call is not having effect?
> But honestly this is beyond me - I don't have any idea what would cause
> Python to ignore that, and I don't see anything in the commit history
> that could be at fault.
> I'm hoping someone can tell me that it's definitely a platform
> configuration issue or it's definitely interference between two of our
> tests (which run in random order, which would explain the intermittent
> nature of this, but I haven't spotted any tests that seem likely either).
> To see the other failed PR builds, the full list is at
> https://dev.azure.com/Python/cpython/_build?definitionId=9 and most of
> the ones from today have failed because of whatever is causing it.
> Any help?
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...