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

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.