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

[Christian Zietz <czietz@xxxxxxx>]

Hello,

 

I checked the last week - and I did receive all emails that are in the archive. Note that this does not necessarily have to mean that the problem is at your end; tuxfamily might have some misconfiguration that prevents delivery to your provider.

 

Regards

Christian

 

PS: Please accept my apology for my annoyed answer to your patch. It makes more sense if you didn't see what I posted about "frsize" vs. "bsize".

 

Gesendet: Freitag, 13. Juni 2025 um 13:06

Von: "Eero Tamminen" <oak@xxxxxxxxxxxxxx>

An: hatari-devel@xxxxxxxxxxxxxxxxxxx

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

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