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

On Sun, 11 Aug 2019 08:57:04 -0600
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?
> 

My understanding of what Rick wrote was that, upon receiving ENOTTY
from the ioctl, lseek() would simply do what he described in (2).
His wording seems perfectly clear to me.

-- 
Gary Jennejohn