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

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Montag, 9. Juni 2025 14:29:03 CEST Christian Zietz wrote:

> The results on macOS are ... interesting:

Yes, i get similar result here:

sizeof(struct statvfs): 64

sizeof(f_blocks): 4

sizeof(f_frsize): 8

sizeof(f_bfree): 4

sizeof(f_bavail): 4

sizeof(f_bsize): 8

f_blocks: 20499474

f_frsize: 4096

f_bfree: 9244724

f_bavail: 9180724

f_bsize: 1048576

the struct seems to be defined as:

struct statvfs {

    unsigned long    f_bsize;    /* File system block size */

    unsigned long    f_frsize;    /* Fundamental file system block size */

    fsblkcnt_t    f_blocks;    /* Blocks on FS in units of f_frsize */

    fsblkcnt_t    f_bfree;    /* Free blocks */

    fsblkcnt_t    f_bavail;    /* Blocks available to non-root */

    fsfilcnt_t    f_files;    /* Total inodes */

    fsfilcnt_t    f_ffree;    /* Free inodes */

    fsfilcnt_t    f_favail;    /* Free inodes for non-root */

    unsigned long    f_fsid;        /* Filesystem ID */

    unsigned long    f_flag;        /* Bit mask of values */

    unsigned long    f_namemax;    /* Max file name length */

};

where "fsblkcnt_t" is unsigned int. But since f_bsize has a rather large value, this will still overflow when you multiply them.

BTW, you could also do similar tests in aranym, when using the hostfs on mint. That will also use statvfs() (but without restriction on the TOS version of course, since those calls will always be issued by a mint kernel, not ROM-TOS).

> Thus, I'm not sure if it correct to use "f_bsize" here.

Hm, yes. But Aranym does the same. On linux atleast, this works. But results there are different:

sizeof(struct statvfs): 112

sizeof(f_blocks): 8

sizeof(f_frsize): 8

sizeof(f_bfree): 8

sizeof(f_bavail): 8

sizeof(f_bsize): 8

f_blocks: 58328544

f_frsize: 4096

f_bfree: 11435407

f_bavail: 8454264

f_bsize: 4096

This is actually the layout of a "struct statvfs64", which is used depending on whether __USE_LARGEFILE64 is defined. Also, f_frsize and f_bsize ar identical. Maybe, for the sake of evaluating free space, it would be better to use f_frsize in all cases? Or atleast on macOS?

The manual page states:

               unsigned long  f_bsize;    /* Filesystem block size */

               unsigned long  f_frsize;   /* Fragment size */

>will just have to accept that�the values on macOS are rubbish.

Not really rubbish, but they seems to be inpreted differently.

BTW. the implementation in coreutils (in lib/fsusage.c) seems to do something like:

      /* f_frsize isn't guaranteed to be supported.  */

      fsp->fsu_blocksize = (vfsd.f_frsize

                            ? PROPAGATE_ALL_ONES (vfsd.f_frsize)

                            : PROPAGATE_ALL_ONES (vfsd.f_bsize));

So it uses f_frsize is that if that is set, f_bsize otherwise.