GeezerVison

Extends PEP 475's retry-on-EINTR behavior to more os functions that take a path (and a few fd-based stragglers). This means these functions can now succeed if a signal arrives during a slow filesystem operation (e.g. networked or user filesystems).

Background

PEP 475 (3.5) added EINTR retry loops to the functions expected to block: read, write, open, fstat, select, sockets, wait*, and so on. The path-based functions (stat, rename, utime, unlink, listdir, ...) were left out on the assumption that they don't block long enough to be interrupted. That assumption doesn't hold on network or userspace filesystems:

• NFSv4 (Linux fs/nfs/nfs4proc.c): when the server answers NFS4ERR_DELAY/GRACE the client backs off in TASK_INTERRUPTIBLE for lookup, getattr, access, readdir, remove, mkdir, open and friends, and any signal makes the syscall return -ERESTARTSYS. Since signal.signal() installs handlers without SA_RESTART, that reaches Python as EINTR. Every path walk goes through lookup/access/getattr, so stat, rename, utime, unlink etc. are all exposed.
• FUSE (fs/fuse/dev.c, request_wait_answer): a request still queued when a signal arrives fails with a hard -EINTR, which SA_RESTART cannot restart. sshfs, rclone, and any other FUSE filesystem can produce this. A userspace retry is the only fix.

The original report came from a program with a SIGCHLD handler doing routine bookkeeping on an NFS mount; every child exit was a chance for a path operation in the main thread to die with EINTR.

os.access() is a special case worth calling out: it reports failure by return value, so before this change an EINTR made it silently return False for a perfectly readable file, with no exception at all.

Changes

Modules/posixmodule.c only. Retry loops added to 30 C functions, covering these Python-level functions:

os.access, os.chdir, os.chflags, os.chmod, os.chown, os.chroot, os.getxattr, os.lchflags, os.lchmod, os.lchown, os.link, os.listdir, os.listxattr, os.lstat, os.mkdir, os.readlink, os.removexattr, os.rename, os.replace, os.rmdir, os.scandir (open, iteration, and DirEntry.stat()/is_*()), os.setxattr, os.stat, os.statvfs, os.statx, os.symlink, os.truncate, os.unlink, os.utime, and os._fcopyfile (macOS).

Behavior on retry matches PEP 475 exactly: on EINTR, run the Python signal handlers via PyErr_CheckSignals(); if none raises, call again; if one raises, propagate that exception. Error reporting is unchanged (path_error, path_error2, etc. are called exactly as before). Windows builds compile the loops but EINTR never occurs there.

The code is mostly mechanical cookie-cutter code as follows, adjusted to conform to function-specific details:

for (;;) {
    Py_BEGIN_ALLOW_THREADS
    result = syscall(...);
    Py_END_ALLOW_THREADS

    // interrupted by a signal (EINTR)?  retry!
    if ((result != 0) && (errno == EINTR)) {
        if (PyErr_CheckSignals()) {
            return NULL;
        }
        continue;
    }
    break;
}

Two pre-existing bugs fixed in passing, in code that had to be restructured anyway:

• os.scandir(fd) on a platform without fdopendir leaked the half-built iterator object when raising TypeError.
• DirEntry.stat() carried an errno save/restore around Py_DECREF that became dead once the error is reported before the decref; removed.

Testing

• Full test suite passes on Linux.
• Every changed function was run through the preprocessor under Linux, macOS, bare-POSIX (no *at functions), and Windows macro sets to verify {} and Py_BEGIN/END_ALLOW_THREADS balance in each configuration.
• A FUSE test harness exercises 15 of the functions, two cases each: handler returns normally → call succeeds and handler ran exactly once; handler raises → that exception propagates. All 30 cases pass with this branch. On an unmodified interpreter, 28 report InterruptedError and the two os.access cases return False for a readable file. (I could post the FUSE test harness if there was interest; it's unavoidably Linux-only.)

Not compiled/tested locally: os_lchmod_impl, os_chflags_impl, os_lchflags_impl, os__fcopyfile_impl. I can't even compile those on my Linux box. Reviewers may want to keep an eye on the macOS job for those.

AI Involvement

I wrote the code, Claude Fable 5.1 wrote the tests and I reviewed them.

Issue: gh-130209