[hatari-devel] Not receiving all mailing list mails (was: GemDOS_DFree)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 13.6.2025 13.24, Christian Zietz wrote:
> As I've explained in a few emails already. I feel we're getting 
nowhere here,

Looking at the hatari-mailing list archive:
https://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2025/06/maillist.html

There are several mails from you and others in last couple of days, that 
I have not received.

=> Everybody, please check from above link whether you've received all 
the mails, and if not, comment here.

I.e. is the problem at my end, or is tuxfamily.org mail sending breaking 
down, like rest of its services?

Note: mailing list archive works with some delay (1 day?), so don't 
worry if mail you've received today, is not yet visible in archive.


	- Eero

PS. This happening right before release is rather inconvenient...


On 13.6.2025 13.24, Christian Zietz wrote:
> Hello,
> you are still using "f_frsize" for "Total", but (conditionally) "f_bsize" for
> "Free". Why? The /same/ multiplier "f_frsize" always applies to /both /values.
> As I've explained in a few emails already. I feel we're getting nowhere here,
> sorry. (Then again, I don't particularly care if Hatari  on macOS is buggy or not.)
> Regards
> Christian
> *Gesendet: *Donnerstag, 12. Juni 2025 um 23:56
> *Von: *"Eero Tamminen" <oak@xxxxxxxxxxxxxx>
> *An: *"Hatari Development" <hatari-devel@xxxxxxxxxxxxxxxxxxx>
> *Betreff: *[hatari-devel] Re: GemDOS_DFree
> Hi,
>
> On 9.6.2025 15.29, Christian Zietz via Emutos-devel wrote:
> ..
>   > The results on macOS are ... interesting:
>   >
>   > sizeof(struct statvfs) = 64
>   > sizeof(f_bfree) = 4
>   > sizeof(f_bavail) = 4
>   > statfs() = 0
>   > f_blocks = 83758080
>   > f_frsize = 4096
>   > f_bfree = 11770043
>   > f_bavail = 11770043
>   > f_bsize = 4161536
>   >
>   > First the members are just 4 bytes (32 bits) long! Then, the total file
>   > system size is specified by POSIX to be "f_blocks*f_frsize". But it is
>   > not clearly specified, whether the free blocks are given in units of
>   > "f_frsize" or "f_bsize". Hatari uses different units for total and free
>   > space: "Total = buf.f_blocks/1024 * buf.f_frsize" and "Free = Free/1024
>   > * buf.f_bsize". But with the values above, this calculation gives more
>   > free space than total space on macOS!
>   >
>   > If we look into how Apple fills these fields:
>   > https://github.com/apple-oss-distributions/Libc/ <https://github.com/apple-
> oss-distributions/Libc/>
>   > blob/63976b830a836a22649b806fe62e8614fe3e5555/emulated/statvfs.c#L35
>   > ... "f_bsize" corresponds to "f_iosize", which is the "optimal transfer
>   > block size". Thus, I'm not sure if it correct to use "f_bsize" here.
>   >
>   > Very confusing. I guess the original post will just have to accept that
>   > the values on macOS are rubbish.
>
> Maybe attached patch would be OK for it?
>
>
> - Eero