The conversion from struct statfs to a statvfs value is based on the implementation in Apple's libc, in particular for the reported maximum filename length.

I'm not entirely sure if how far back we should back port this. The patch is clean so could easily be back ported to 3.10, but is conceptually a fairly large change.

@ronaldoussoren Do you think you might revisit this? :)

@ronaldoussoren Do you think you might revisit this? :)

I am revisiting this. Finally...

In your PR you rightly mapMNT_RDONLY andMNT_NOSUID toST_RDONLY andST_NOSUID (note: you can also mapMNT_NOEXEC toST_NOEXEC) , but the otherST_* flags are lost. I'm not sure if this is appropriate, but perhaps it would make sense to call bothstatvfs andfstatfs, and use the former to fetch all flags.

The statvfs implementation on macOS:https://github.com/apple-oss-distributions/Libc/blob/c5a3293354e22262702a3add5b2dfc9bb0b93b85/emulated/statvfs.c#L35

As you can see this implementation does not implement flags other thanST_RDONLY andST_NOSUID.AddingST_NOEXEC is easy enough, as isST_NODEV. But callingstatvfs(3) to get other flags doesn't give us more information.

The current manual page, and SDK headers, only list two flags:

     There are two flags defined for the f_flag member:           ST_RDONLY      The file system is mounted read-only.           ST_NOSUID      The semantics of the S_ISUID and S_ISGID file mode bits are not supported by, or are disabled on, this file system.

That's another reason to not callstatvfs: There are no other flags to expose than the ones we already emulate.

@Yhg1s and@pablogsal : What's your opinion on back porting this to 3.12 and 3.11?

The PR reimplementsos.statvfs on macOS, but should result in the same behaviour other than fixing the problem with large disks because I based it on Apple implementation ofstatvfs(3).

@Yhg1s and@pablogsal : What's your opinion on back porting this to 3.12 and 3.11?

The PR reimplementsos.statvfs on macOS, but should result in the same behaviour other than fixing the problem with large disks because I based it on Apple implementation ofstatvfs(3).

I won't backport to 3.11 and 3.12, the change is too large for that (IMHO)

Follow up:#115236

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotAMD64 Windows10 3.x has failed when building commit6e222a5.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/146/builds/7668) and take a look at the build logs.
4. Check if the failure is related to this commit (6e222a5) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/146/builds/7668

Failed tests:

• test.test_concurrent_futures.test_shutdown

Failed subtests:

• test_interpreter_shutdown - test.test_concurrent_futures.test_shutdown.ProcessPoolSpawnProcessPoolShutdownTest.test_interpreter_shutdown

Summary of the results of the build (if available):

==

Traceback (most recent call last):  File"D:\buildarea\3.x.bolen-windows10\build\Lib\test\test_concurrent_futures\test_shutdown.py", line50, intest_interpreter_shutdownself.assertEqual(out.strip(),b"apple")~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^AssertionError:b'' != b'apple'