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

2024-02-22 Thread Crystal Kolipe
On Thu, Feb 22, 2024 at 08:13:28AM -0500, Mouse wrote: > >>> lseek(fd, 0, SEEK_END); > [on a disk device] > > >> [...] > > [...] > > This is such a buggy behaviour that [...] > > I wouldn't call it buggy, not unless there is a spec that it's supposed > to conform to that says otherwise (even if

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

2024-02-22 Thread Mouse
>>> lseek(fd, 0, SEEK_END); [on a disk device] >> [...] > [...] > This is such a buggy behaviour that [...] 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

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

2024-02-22 Thread Sad Clouds
Hello, thanks to everyone who responded with their suggestions. Using various non-portable ioctls I can device size on most platforms, for both block and raw devices. This is more convoluted than a single lseek() call, but it is what it is. If anyone wants to do something similar, then the

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

2024-02-22 Thread Michael van Elst
mlel...@serpens.de (Michael van Elst) writes: >But it also does not work for wedges or device mapper volumes >(zfs vol probably fail too) as these don't implement the >used internal ioctl for disk devices. At least that part >would be easy to fix, but of questionable value. Like this: Index: