First of all, there is a race condition:
454: with open(self._lockfile) as fp:
455: return fp.read()
Between open() and read(), the lockfile may get deleted, or linked to another claim file, by another process. This cause a ESTALE (116) error. I believe ESTALE error must be handled here, even if user didn't include it in retry_errnos.
Secondly, I guess Nicolas is probably working on some older version of Linux/BSD.
According to this [http://irccrew.org/~cras/nfs-coding-howto.html#estale], the next call to open() will return the correct file handler. However, on older systems, the attribute cache on the client still contains the wrong file handler, and open() could fail with ESTALE as well. Only after a refreshing of attribute cache (every 30s or so), open() will succeed.
The better solution probably is to force refresh the parent directory's attribute cache after ESTALE is caught.