Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA)

Konstantin Belousov kostikbel at gmail.com
Mon Feb 1 16:56:54 UTC 2016


On Mon, Feb 01, 2016 at 07:57:40AM -0800, Maxim Sobolev wrote:
> Hi,
> 
> I've noticed that lseek() behaved inconsistently with regards to SEEK_HOLE
> and SEEK_DATA operations. The SEEK_HOLE on a data-only file returns st_size
> (i.e. EOF + 1), while the SEEK_DATA on a hole-only file returns -1 and sets
> errno to ENXIO. The latter seems to be a documented way to indicate that
> the file has no more data sections past this point.
> 
> My first idea was that somehow most files has a hole attached to its end to
> fill up the FS block, but that does not seem to be a case. Trying to
> SEEK_HOLE past the end of any of those data-only files produces an error
> (i.e. lseek(fd, st_size, SEEK_HOLE) == -1).
> 
> In short, for some reason I cannot get proper ENXIO from the SEEK_HOLE.
> What currently returned implies that there is 1-byte hole attached to each
> file past its EOF and that does not smell right.
> 
> All tests are done on UFS, fairly recent 11-current.
> 

There is no 'hole-only' files on UFS, the last byte in the UFS file must
be populated, either by allocated fragment if the last byte is in the
direct blocks range, or by the full block if in the indirect range.

Please show an exact minimal test case which reproduces what you
consider the bug, with the comment about the expected outcome in the
failing location.


More information about the freebsd-fs mailing list