From cdb93eefec597b7fa42dc9ef175a6412caa5ce95 Mon Sep 17 00:00:00 2001 From: Dustin Dettmer Date: Wed, 8 Sep 2021 10:57:37 -0700 Subject: [PATCH] resolve() appears broken on Python 3.7+ On my machine it should have produced: /tmp/ltests-1p0v5z1j/.locks/lock-1631090663.1066182 but instead it produced: /private/tmp/ltests-1p0v5z1j/.locks/lock-1631090663.105848 The mismatch resulted in a hang inside flock. Path .resolve() seems to be causing problems for others as well. It appears the library was not meant to handle complex path situations and isn't maintained as such (see link reference). Since we have already built a full path here anyway, the call to .resolve() appears redundant. Tested on python 3.9.6 on my Mac OS X 11.4 (20F71), Xcode 12.5.1 (12E507) Relevant discussion: https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573 --- contrib/pyln-testing/pyln/testing/utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/pyln-testing/pyln/testing/utils.py b/contrib/pyln-testing/pyln/testing/utils.py index 7f8cd0fb4..14e93a9e7 100644 --- a/contrib/pyln-testing/pyln/testing/utils.py +++ b/contrib/pyln-testing/pyln/testing/utils.py @@ -1151,7 +1151,7 @@ def flock(directory: Path): # So now we have a position in the lock, let's check if we are the # next one to go: while True: - files = sorted([f.resolve() for f in d.iterdir() if f.is_file()]) + files = sorted([f for f in d.iterdir() if f.is_file()]) # We're queued, so it should at least have us. assert len(files) >= 1 if files[0] == fname: