Re: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sat, 17 Aug 2019 03:39:14 +0000
Ian Lepore wrote:
>On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote:
>> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore <ian_at_freebsd.org> wrote:
>> >
>> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote:
>> > > On Sun, 11 Aug 2019 02:03:10 +0000
>> > > Rick Macklem <rmacklem_at_uoguelph.ca> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a
>> > > > file
>> > > > that
>> > > > resides in a file system that does not support holes, ENOTTY is
>> > > > returned.
>> > > >
>> > > > This error isn't listed for lseek() and seems a liitle weird.
>> > > >
>> > >
>> > > ENOTTY is the standard error return for an unimplemented
>> > > ioctl(2),
>> > > and SEEK_HOLE ultimately becomes a call to fo_ioctl().
>> > >
>> > > > I can see a couple of alternatives to this:
>> > > > 1 - Return a different error. Maybe ENXIO?
>> > > > or
>> > > > 2 - Have lseek() do the trivial implementation when the
>> > > > VOP_IOCTL()
>> > > > fails.
>> > > >    - For SEEK_DATA, just return the offset given as argument
>> > > > and
>> > > > for SEEK_HOLE
>> > > >       return the file's size as the offset.
>> > > >
>> > > > What do others think? rick
>> > > > ps: The man page should be updated, whatever is done w.r.t.
>> > > > this.
>> > > >
>> > >
>> > > I also vote for option 2
>> > >
>> >
>> > If SEEK_DATA and SEEK_HOLE don't return the standard "ioctl not
>> > supported" error code and return a fake result, how are you
>> > supposed to
>> > determine at runtime whether SEEK_HOLE is supported or not?
>> >
>> > -- Ian
>>
>> pathconf(2) will tell you.
>>
>
>Ahh, I wasn't aware of that.
>
>For option 2, lseek() has to not just return the info, but must also
>actually set the file position accordingly, and has to treat offset >=
>filesize as an error.

I have put a patch for this at https://reviews.freebsd.org/D21299
I listed markj_at_ as a reviewer, but anyone is welcome to review it, if they'd like.

Since vn_bmap_seekhole() can return ENOTTY, the above patch follows that
convention as well.

I also have a trivial patch to map errnos not specified for lseek() to EINVAL.
https://reviews.freebsd.org/D21300.
Ditto above w.r.t. to reviewing it.

rick
Received on Sat Aug 17 2019 - 01:39:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC