On Mon, 26 Feb 2024 09:20:21 -0500
Thor Lancelot Simon wrote:
> On Sun, Feb 25, 2024 at 04:41:37PM +, Sad Clouds wrote:
> >
> > The whole idea of Unix was "everything is a file" and the sooner people
> > get rid of magic ioctls the better.
>
> But everything is *not*, actually, a file, and
On Sun, Feb 25, 2024 at 04:16:03AM -, Michael van Elst wrote:
> t...@panix.com (Thor Lancelot Simon) writes:
>
> >Probably not a good idea to start with lseek() because if you _do_
> >encounter a tape device, seeking to SEEK_END could take you an extremely
> >long time.
>
> lseek() doesn't
On Sun, Feb 25, 2024 at 04:41:37PM +, Sad Clouds wrote:
>
> The whole idea of Unix was "everything is a file" and the sooner people
> get rid of magic ioctls the better.
But everything is *not*, actually, a file, and forcing things that
are not files into file-like shapes is not always the
On Sun, 25 Feb 2024 07:21:07 -0300
Crystal Kolipe wrote:
> In most cases, unless we are talking about a low-level disk utility, if
> userland code is trying to find out the size of a raw block device then it
> seems like a design error.
There are many valid reason why applications may want to
> On Feb 25, 2024, at 12:29 AM, Robert Elz wrote:
>
> ps: as a semi-related anecdote, the first system I ever personally
> installed any unix version onto (way back in the mid 70's) booted from
> a reel to reel (1/2" I think) tape - and by booted, I mean ran with its
> filesystems (or
On Sat, Feb 24, 2024 at 10:54:56PM +, Taylor R Campbell wrote:
> > Date: Sat, 24 Feb 2024 16:21:42 -0500
> > From: Thor Lancelot Simon
> >
> > On Wed, Feb 21, 2024 at 09:20:55PM +, Taylor R Campbell wrote:
> > > I think this is a bug, and it would be great if stat(2) just returned
> > >
On Sat, 24 Feb 2024 16:28:28 -0500
Thor Lancelot Simon wrote:
> On Thu, Feb 22, 2024 at 12:08:14PM +, Sad Clouds wrote:
> > 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
Date:Sun, 25 Feb 2024 04:16:03 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| lseek() doesn't move the tape. But the open() or close() may trigger
| tape operations like loading or winding. Special files are special.
The issue is more the
On Sat, Feb 24, 2024 at 04:28:28PM -0500, Thor Lancelot Simon wrote:
> > 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
t...@panix.com (Thor Lancelot Simon) writes:
>Probably not a good idea to start with lseek() because if you _do_
>encounter a tape device, seeking to SEEK_END could take you an extremely
>long time.
lseek() doesn't move the tape. But the open() or close() may trigger
tape operations like loading
> Date: Sat, 24 Feb 2024 16:21:42 -0500
> From: Thor Lancelot Simon
>
> On Wed, Feb 21, 2024 at 09:20:55PM +, Taylor R Campbell wrote:
> > I think this is a bug, and it would be great if stat(2) just returned
> > the physical medium's size in st_size -- currently doing this reliably
> >
On Thu, Feb 22, 2024 at 12:08:14PM +, Sad Clouds wrote:
> 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
On Wed, Feb 21, 2024 at 09:20:55PM +, Taylor R Campbell wrote:
> > Date: Wed, 21 Feb 2024 10:52:55 +
> > From: Sad Clouds
> >
> > Hello, for most operating systems determining the size of a block
> > device can be done with:
> >
> > lseek(fd, 0, SEEK_END);
> >
> > However, on NetBSD
On Thu, Feb 22, 2024 at 05:47:55AM +, Sad Clouds wrote:
> On Wed, 21 Feb 2024 12:48:34 -0800
> Jason Thorpe wrote:
>
> >
> > > On Feb 21, 2024, at 2:52???AM, Sad Clouds
> > > wrote:
> > >
> > > Hello, for most operating systems determining the size of a block
> > > device can be done
>> 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".
Well...maybe. Depends on whose expectations. If I expect, say, that
typing a tab on a command line puts a
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
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
>>> 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
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
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:
cryintotheblue...@gmail.com (Sad Clouds) writes:
>Hello, for most operating systems determining the size of a block
>device can be done with:
>lseek(fd, 0, SEEK_END);
>However, on NetBSD this does not seem to work.
The disk size is only retrieved at open time and stored in the
cached vnode.
On Wed, 21 Feb 2024 12:48:34 -0800
Jason Thorpe wrote:
>
> > On Feb 21, 2024, at 2:52 AM, Sad Clouds wrote:
> >
> > Hello, for most operating systems determining the size of a block
> > device can be done with:
> >
> > lseek(fd, 0, SEEK_END);
>
> On what operating systems does this do what
On Wed, Feb 21, 2024 at 09:20:55PM +, Taylor R Campbell wrote:
> But it's a little annoying to make that happen because it requires
> going through all the file systems that have device nodes and
> convincing their VOP_GETATTR implementations to do something different
> for block devices
(This should really be on tech-kern…)
> On Feb 21, 2024, at 1:20 PM, Taylor R Campbell
> wrote:
>
>> Date: Wed, 21 Feb 2024 10:52:55 +
>> From: Sad Clouds
>>
>> Hello, for most operating systems determining the size of a block
>> device can be done with:
>>
>> lseek(fd, 0, SEEK_END);
>>
> Date: Wed, 21 Feb 2024 10:52:55 +
> From: Sad Clouds
>
> Hello, for most operating systems determining the size of a block
> device can be done with:
>
> lseek(fd, 0, SEEK_END);
>
> However, on NetBSD this does not seem to work.
Internally, this is happens for more or less the same
> On Feb 21, 2024, at 2:52 AM, Sad Clouds wrote:
>
> Hello, for most operating systems determining the size of a block
> device can be done with:
>
> lseek(fd, 0, SEEK_END);
On what operating systems does this do what you claim?
> However, on NetBSD this does not seem to work.
It doesn’t
Hello, for most operating systems determining the size of a block
device can be done with:
lseek(fd, 0, SEEK_END);
However, on NetBSD this does not seem to work.
#include
#include
#include
#include
#include
int main(void)
{
int fd;
off_t offset;
fd =
27 matches
Mail list logo
