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

[Ian Lepore]

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