MacOS BigSur (and older), python 3.9.2 (and older)

For disks >4TB, os.statvfs() shows a wrong value for available space: too low, and always rollover at each 4TB. 
As 4TB = 2^42, hypothesis: rollover in 32bit counter (with 10bit blocksize)

Example:

"df -m" does show the correct available space

df -m /Volumes/Frank/
Filesystem                                    1M-blocks    Used Available Capacity    iused       ifree %iused  Mounted on
//frank@SynologyBlabla._smb._tcp.local/Frank  21963360 2527744  19435615    12% 2588410474 19902070164   12%   /Volumes/Frank

So available space 19902070164 MB, so about 18.5 TB. Good.

Now python's os.statvfs():

>>> s = os.statvfs("/Volumes/Frank")
>>> s.f_bavail * s.f_frsize / 1024**2
2658399.39453125

So 2.5TB, and thus wrong

The difference is 16777216 MB which is exactly 4 times 4TB.

Problem seems to be in MacOS statvfs() itself; reproducable with a few lines of C code.

We have implemented a workaround in our python program SABnzbd to directly use MacOS' libc statfs() call (not statvfs() ). A solution / workaround in python itself would be much nicer.


No problem with python on Linux with >4TB drives.

Correction on typo in original post / to be clear:

From the "df -m /Volumes/Frank/", Available is 19435615 in unity of 1MB blocks, so 19435615 MB. Which is 18.5 TB. All correctly reported by "df -m". But not by os.statvfs()

As you note in the title this is a 32-bit overflow in the statvfs system API, the struct it uses contains 32-bit values.

OK. What would be a solution from/for Python to get the correct available space on a MacOS system?

In SABnzbd we implemented a workaround with a direct call to MacOS C lib's statfs(). See https://github.com/sabnzbd/sabnzbd/blob/develop/sabnzbd/filesystem.py#L948-L989

IMHO not a great solution for a python programmer. Could python's os.statvfs() use the correct (64bit) info from statfs()?