Re: Subject: Re: pkg/57496

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/57496; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Henryk Paluch <hpaluch%seznam.cz@localhost>
Subject: Re: Subject: Re: pkg/57496
Date: Sun, 02 Jul 2023 18:16:38 +0700

 I suspect you're right.
 
 This might have been caused by an unfortunate disparity between
 the NetBSD kernel's internal getdisksize() routine, and the one
 essentially all of userland shares, which comes from src/sbin/fsck/partutil.c
 
 Both of them have 3 params, the first identifies the disk in question
 (quite differently, but that doesn't matter), the other two are pointers
 to where the two results are to be stored.
 
 The kernel's version returns the sector size, and the number of sectors.
 
 partutil's version returns the sector size, and the media size (the product
 of the number of sectors and the sector size).
 
 With the kernel version, multiplying the two results is the correct way
 to determine the total size, but as you determined, is completely the wrong
 thing to do for the partutil version (which instead requires the user to
 divide the media size by the sector size, if the number of sectors is wanted).
 
 The partutil version is included (by file copy, effectively) in fuse-exfat in
 	patches/patch-libexfat__nbpartutil.[ch]
 But the patch in
 	patches/patch-libexfat__io.c
 
 is assuming that it works more like the kernel version (though correctly
 using the partutil version parameter order).   The latter patch needs to be
 regenerated with the change you identified.
 
 kre