===
os.posix_fallocate(os.open('qwe.qwe', os.O_RDONLY|os.O_CREAT), 0, 1024*1024)
===

generates OSError with errno 0. Suppose this happen due to O_RDONLY flag.

strace :

====
open("qwe.qwe", O_RDONLY|O_CREAT|O_CLOEXEC, 0777) = 3
fallocate(3, 0, 0, 1048576)             = -1 EBADF (Bad file descriptor)
====


Python 3.5.3, Ubuntu 64-bit.

man posix_fallocate:

RETURN VALUE

posix_fallocate() returns zero on success, or an error number on failure.  Note that errno is not set.

Also, EINTR will not be caught too (!)

https://github.com/python/cpython/pull/3000

All checks passed.

Please merge.

posix_fadvise() is also affected :(

Fixed in this patch.

Adding Larry who is listed as posix expert.

New changeset d4b93e21c2664d6a78e0656e7a7be0807be1c352 by larryhastings (Коренберг Марк) in branch 'master':
bpo-31106: Fix handling of erros in posix_fallocate() and posix_fadvise() (#3000) (#3000)
https://github.com/python/cpython/commit/d4b93e21c2664d6a78e0656e7a7be0807be1c352

Needed a NEWS entry.

If I understand right, Python 3.5 will not be fixed with this pathc. Right ?

If yes, I will tell Debian maintainers to backport this patch to Python 3.5, which is shipped with latest stable Debian 9.

You understand correctly.  It won't be backported to Python 3.5.

Марк, do you mind to add a NEWS entry?

Yes, I can. Should I create new PR ? to which branch ?

New changeset 3a04c52a9eb03e31c60037248b872f3662002a4d by Andrew Svetlov (Miss Islington (bot)) in branch '3.6':
bpo-31106: Fix handling of erros in posix_fallocate() and posix_fadvise() (GH-3000) (GH-3000) (#4101)
https://github.com/python/cpython/commit/3a04c52a9eb03e31c60037248b872f3662002a4d

I believe changeset d4b93e21c2664d6a78e0656e7a7be0807be1c352 may be the cause of buildbot failures on FreeBSD (at least koobs-freebsd-current, log attached), due to only the EBADF error being handled (not EINVAL, et al).

Unfortunately the worker was been offline for a longer than anticipated period of time and only recently was restored which delayed picking it up.

The issue (in this workers case) is related to the buildbot home/data directory being on a ZFS filesystem, who's host was recently updated (from current late last year to yesterday).

Initial investigation/isolation/references:

Disable posix_fallocate(2) for ZFS
https://lists.freebsd.org/pipermail/svn-src-head/2017-November/105709.html

Note: Above change will be relevant (merged) for at least FreeBSD 12 and 11, but perhaps even 10.

0000684: posix_fallocate() should be allowed to return ENOTSUP (Interp Status: Approved)
http://austingroupbugs.net/view.php?id=684

[HEADS UP] posix_fallocate support removed from ZFS, lld affected
https://lists.freebsd.org/pipermail/freebsd-current/2017-November/067463.html
Snip: "illumos and ZoL seem to do the same."

Gold fails when output file is lying on ZFS 
https://sourceware.org/bugzilla/show_bug.cgi?id=22540

Given the wide scope of use of zfs and both syscalls across multiple OS's, and possible changes to POSIX documentation/standards, changes to the underlying fallocate/fadvise functions may also be indicated here.

The failed test is test_posix_fallocate, not test_posix_fallocate_errno. The former special-cases Solaris for EINVAL already, and the latter merely passes an invalid descriptor.

It seems that this particular issue is still open only because there is no NEWS entry in the merged commits.

I agree with Alexey's analysis.

Koobs, could you please open a new issue about the failing test?  Unless someone knows of a foolproof way to determine on all platforms that a file is resident on ZFS, the fix is to skip the test on FreeBSD as well if ZFS is likely to be used there.

Also, can someone add a NEWS entry and close this issue?

Considering we have already shipped this fix in 3.6.5, I guess we can live without a NEWS entry at this point -> closing this issue.

P.S.:
> Koobs, could you please open a new issue about the failing test?  Unless someone knows of a foolproof way to determine on all platforms that a file is resident on ZFS, the fix is to skip the test on FreeBSD as well if ZFS is likely to be used there.

The unrelated problem identified in msg312453 has now been fixed in Issue33655.