homepage

Seen on "X86 Tiger 2.7" buildbot (http://buildbot.python.org/all/builders/x86%20Tiger%202.7)
test_surrogates (test.test_fileio.OtherFileTests) ... test test_fileio failed -- Traceback (most recent call last):
 File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_fileio.py", line 455, in test_surrogates
 self.fail('Bad output: %r' % out)
AssertionError: Bad output: 'Traceback (most recent call last):\n File "<string>", line 1, in <module>\nIOError: [Errno 22] Invalid argument: \'\\xed\\xb2\\x80.txt\'\n[20282 refs]\n'
Looking into it a bit, the test attempts to open a file with a filename containing surrogates. On OS X 10.4 (Tiger), an attempt to open such a file on a standard HFS+ file system appears to always fail with the above error 22 (EINVAL), rather than error 2 (ENOENT) "No such file or directory" as the test expects and as more recent versions of OS X do. So the test should probably be changed to expect either error code. I'm attaching a patch that should do that.
However, there is another issue. The test does not always fail on 10.4 as one would expect. The test on the buildbot sometimes succeeds. On my own 10.4 system, while I predictably receive an EINVAL when attempting to open the file, running test_fileio in isolation seems to always pass and it's not obvious why it does. The first part of the test, the local open fails as expected but, without the patch, the test of an open in a subprocess passes when it should be failing. But I was able to reproduce the Error 22 failure, as seen on the buildbot failures, with the same interpreter build by using a --randseed value from one of the buildbot failures. So there appears to be a test interaction problem here as well (environment variables?).
/python.exe -Wd -3 -E -tt -R ./Lib/test/regrtest.py -uall -rwW --randseed=2535964

After writing the simplest possible test of open(2) in C to eliminate anything in Python, I finally established that the seemingly random behavior of the test is in fact caused by a rather odd bug in OS X 10.4. The filename being used in the test is intended to be invalidly encoded. On 10.4, open(2) of that filename returns errno 2 (ENOENT) as expected *if* the containing directory is empty. But if there is at least one existing file in the directory, the open returns errno 22 (EINVAL) instead. Go figure! Knowing that, it's easy to reproduce the test failure by running the test directly. So, the buildbot failures are intermittent depending on what files previous tests have left behind in the working directory. (I haven't checked intermediate versions but current OS X 10.8 does not have this odd behavior: ENOENT is always returned.) The original proposed solution still seems to me to be the right one: simply change the test to pass if either EINVAL or ENOENT is returned.

New changeset 9497adb7355f by Ned Deily in branch '2.7':
Issue #17111: Prevent test_surrogates (test_fileio) failure on OS X 10.4.
http://hg.python.org/cpython/rev/9497adb7355f