Linux 3.15 and newer support a vastly superior API for file locking, in which locks are owned by open file descriptions instead of by processes.  This is how everyone seems to expect POSIX locks to work, but now they can finally work that way.

Please add some interface to these locks to fcntl.lockf.  One option would be to use them by default and to fall back to standard POSIX locks if they're not available.  I don't know whether this would break existing code.

See http://man7.org/linux/man-pages/man2/fcntl.2.html for details.

I'd like to use fd locks from python too.

This implements the open_file_descriptor argument and fixes a bug with converting to int when off_t is 64-bit but long is 32-bit.

> This implements the open_file_descriptor argument and fixes a bug with converting to int when off_t is 64-bit but long is 32-bit.

Please extract the fix into a different patch.

Strange, Rietveld (the tool linked with the [review] button) doesn't show the change on the Modules/fcntlmodule.c file.

By the way, I suggest to not include the Modules/clinic/fcntlmodule.c.h change in the patch.

Here is the OFD patch, I'll open another issue for the overflow bug.

On issue 38602, the constant related to open file descriptors will be added.
I will finalize this issue after issue 38602 is closed.

> On issue 38602, the constant related to open file descriptors will be added. I will finalize this issue after issue 38602 is closed.

issue 38602 added constants, but this issue also modify lockf() to add open_file_descriptor parameter to choose between F_SETLK/F_SETLKW and F_OFD_SETLK/F_OFD_SETLKW.

New changeset befa032d8869e0fab4732d910f3887642879d644 by Serhiy Storchaka (Dong-hee Na) in branch 'master':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/befa032d8869e0fab4732d910f3887642879d644

New changeset 85e415108226cc5f3fdddd70196fc4c2a1d0f7f4 by Miss Islington (bot) in branch '3.8':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/85e415108226cc5f3fdddd70196fc4c2a1d0f7f4

New changeset 917dbe350a762ed6d75b7d074f3fb87975ba717b by Miss Islington (bot) in branch '3.7':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/917dbe350a762ed6d75b7d074f3fb87975ba717b

One question:
Is there any reason to choose the name is `open_file_descriptor` not `open_file_description`?

According to https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks.html

It is important to distinguish between the open file description (an instance of an open file, usually created by a call to open) and an open file descriptor, which is a numeric value that refers to the open file description. The locks described here are associated with the open file description and not the open file descriptor

Failure on x86-64 High Sierra 3.8:
https://buildbot.python.org/all/#/builders/226/builds/519

Please fix tests, or revert your change:
https://pythondev.readthedocs.io/ci.html#revert-on-fail

======================================================================
ERROR: test_lockf_exclusive (test.test_fcntl.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/test/test_fcntl.py", line 149, in test_lockf_exclusive
    p.start()
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_exclusive.<locals>.try_lockf_on_other_process'

======================================================================
ERROR: test_lockf_share (test.test_fcntl.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/test/test_fcntl.py", line 163, in test_lockf_share
    p.start()
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_share.<locals>.try_lockf_on_other_process'

@vstinner

Victor, Thanks for letting me know.
It was reproduced on my mac machine so I fix the test.
Please take a look.

@corona10

The AIX bot's are also in the red zone with PR17010.

This was examined earlier See: https://bugs.python.org/issue35633#msg333662

In short, the recommendation by Victor was to skip the test: quote:
> On AIX the test for flock() passes, but the test for lockf() fails: (...)

I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. 

And so,  Lib/test/eintrdata/eintr_tester.py now has:

    @unittest.skipIf(platform.system() == "AIX", "AIX returns PermissionError")
    def test_lockf(self):
        self._lock(fcntl.lockf, "lockf")


Thanks for your understanding.

@Michael.Felt

Thanks for the suggestion.
I 've updated the PR to skip the test on AIX.

cc @vstinner

Dear Core developers

Although I updated the unit test for this issue if the reverting is a better way. Please let me know.
I am happy to follow the decision. :)

Thanks always

Could PR17010 be reverted?

For 10 days now several bots, AIX and  x86-64 High Sierra - afaik, are failing the tests.

re: https://bugs.python.org/issue22367#msg356614 - while that may address High Sierra, it does not address AIX.

See message https://bugs.python.org/issue35633#msg333662 - wherein Victor states his preference to ignore the test (for AIX).

A additional change to your next PR could be to also ignore AIX for this test. AIX returns a different error, "Permission Error", iirc.

ignore my last comment - I missed your comment about skipping the test. My apologies.

I'll be patient.

Thanks for the update!

This cause of failure PR 17010 was due to change of start methods as follows:
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
Changed in version 3.8: On macOS, the spawn start method is now the default. The fork start method should be considered unsafe as it can lead to crashes of the subprocess. See bpo-33725.


So I updated the test through PR 17154 and I check that my local mac machine works well. (I did not check it on my local mac machine when I submitted PR 17010 since open description lock was Linux feature, this was my mistake)

And thanks to the tip from Michael Felt, I update the test to skip on the AIX machine. So I expect that when PR 17154 is landed, everything will go well.

➜  cpython git:(bpo-22367-test-fix) ✗ ./python.exe Lib/test/test_fcntl.py -v
struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
test_fcntl_64_bit (__main__.TestFcntl) ... skipped 'F_NOTIFY or DN_MULTISHOT unavailable'
test_fcntl_bad_file (__main__.TestFcntl) ... ok
test_fcntl_bad_file_overflow (__main__.TestFcntl) ... ok
test_fcntl_f_getpath (__main__.TestFcntl) ... ok
test_fcntl_file_descriptor (__main__.TestFcntl) ... Status from fcntl with O_NONBLOCK:  0
String from fcntl with F_SETLKW:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_fcntl_fileno (__main__.TestFcntl) ... Status from fcntl with O_NONBLOCK:  0
String from fcntl with F_SETLKW:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_flock (__main__.TestFcntl) ... ok
test_flock_overflow (__main__.TestFcntl) ... ok
test_lockf_exclusive (__main__.TestFcntl) ... struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_lockf_share (__main__.TestFcntl) ... struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok

----------------------------------------------------------------------

Ran 10 tests in 0.246s

OK (skipped=1)

Bump.  Serhiy, are you planning to follow up on this?

FYI: I loaded the pr just now and tested on AIX.

$ ./python -m test test_fcntl
0:00:00 Run tests sequentially
0:00:00 [1/1] test_fcntl

== Tests result: SUCCESS ==

1 test OK.

Total duration: 767 ms
Tests result: SUCCESS

$ git status
On branch pr_17154

Thanks

Note: this is affecting the release of Python 3.9.0a1.  I will be continuing with the release in 12 hours.  If the failing macOS test is not fixed by then, alpha1 will ship in this state.

However, I will be blocking alpha2 if this is still the case.

Please prioritize fixing this.

Steve approved this PR 17154 but we need one more reviewer to review this PR.
I hope we can reflect PR 17154 before alpha1 is released.

New changeset 9960230f76eb555d6dfbe8a324efed35610c85f9 by Łukasz Langa (Dong-hee Na) in branch 'master':
bpo-22367: Update test_fcntl.py for spawn process mode (#17154)
https://github.com/python/cpython/commit/9960230f76eb555d6dfbe8a324efed35610c85f9

https://dev.azure.com/python/cpython/_build/results?buildId=54136&view=results

Looks okay at this time.
It was nerve-racking, I worried about my mistake affect publishing Python 3.9.0 alpha1.

Thank you everyone who helps me.

Thanks for the update to the PR

FYI One AIX bot seems to be having support issues atm (and stays red), but the other one turned green again. :smile:

p.s. the new PR also needs to be backported for the 3.8 bots.

> p.s. the new PR also needs to be backported for the 3.8 bots.

PR 17252 and PR 17253 are backporting patches.
And they are ready to be merged :)

Thank you for the following up on this issue.

And the other AIX bot has been repaired, and is running green as well!

:)

New changeset c3cd0de9ec7ab54186cebef5b2edfd098f7ae387 by Victor Stinner (Miss Islington (bot)) in branch '3.8':
bpo-22367: Update test_fcntl.py for spawn process mode (GH-17154) (GH-17252)
https://github.com/python/cpython/commit/c3cd0de9ec7ab54186cebef5b2edfd098f7ae387

New changeset d4d79209e69d52ea4c047545c6c60c3ba75f15f4 by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-22367: Update test_fcntl.py for spawn process mode (GH-17154) (GH-17253)
https://github.com/python/cpython/commit/d4d79209e69d52ea4c047545c6c60c3ba75f15f4

It looks like the only thing left to do yet for this issue is to finish the review of and merge the PR that actually implements the new parameter.  Removing the Deferred Blocker status and deselecting releases other than 3.9.