Re: Issues with lseek(2) on a block device

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Feb 22, 2024 at 08:13:28AM -0500, Mouse wrote:
 > I wouldn't call it buggy, not unless there is a spec that it's supposed
 > to conform to that says otherwise (even if the "spec" is just an
 > author's description of intent), which is something I so far haven't
 > seen reason to think exists.  It looks to me like "we didn't bother
 > making it do anything in particular, so you get whatever it happens to
 > give you".

"bug" ultimately means "failure to conform to expectations". We could
debate what expectations might be for stat and block device sizes, but
it is definitely against expectations that something so simple as
retrieving the size of a storage device has such a messy interface.
 > My own method of finding disk device size is to lseek to offset N and

 > try to read one sector, for various N: initially N = sector size, then
 > double N until I get EOF-or-error, then do binary search between the
 > last working value and the first failing value.  I think that's worked
 > on everything I've tried it on; admittedly, that's only a few OSes, but
 > I'd expect it to be highly portable.  The only cases I'd expect it to
 > fail in are disks over 4G (or perhaps 2G) on systems with only 32 bits
 > for off_t.

...or tapes.

-- 
David A. Holland
dholland%netbsd.org@localhost