[hatari-devel] GemDOS_DFree (was: EmuTOS 1.4 on Hatari 2.5.0)

[Christian Zietz <czietz@xxxxxxx>]

NOTE: I'm moving this discussion over to the Hatari mailing list, as it 
is not an EmuTOS issue. See emutos-devel how it started: 
https://sourceforge.net/p/emutos/mailman/emutos-devel/thread/bf8eb83e-f392-42ea-812a-0188e24ab0d2%40helsinkinet.fi/#msg59192999.

Thorsten Otto via Emutos-devel schrieb:

> But could still be a problem there. The code uses local int variables,

Yes, see the email I sent a few hours before yours:
https://sourceforge.net/p/emutos/mailman/emutos-devel/thread/45460795-128b-408c-9c7e-230ed8a458ba%40gmx.net/#msg59193010

> which may overflow (most likely on modern systems, the members in 
> statvfs are int64_t)

I made a little test program and ran it on GitHub (where one has access 
to macOS):

>     struct statvfs x;
>     int rv;
>
>     printf("sizeof(struct statvfs) = %ld\n", (long)sizeof(struct statvfs));
>     printf("sizeof(f_bfree) = %ld\n", (long)sizeof(x.f_bfree));
>     printf("sizeof(f_bavail) = %ld\n", (long)sizeof(x.f_bavail));
>
>     rv = statvfs("/", &x);
>     printf("statfs() = %d\n", rv);
>     printf("f_blocks = %ld\n", (long)x.f_blocks);
>     printf("f_frsize = %ld\n", (long)x.f_frsize);
>     printf("f_bfree = %ld\n", (long)x.f_bfree);
>     printf("f_bavail = %ld\n", (long)x.f_bavail);
>     printf("f_bsize = %ld\n", (long)x.f_bsize);

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/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.

In any case, this does not seem to be a regression within Hatari.

Regards
Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: https://www.chzsoft.de/
New GnuPG-Key-ID: 0x8708B34C827B159E