homepage

This is likely a FreeBSD 9 kernel bug.
Using this code under python 3, on a ZFS filesystem:
"""
import os
f = open("test", "wb")
f.write(b"hello")
f.flush()
print(os.lseek(f.fileno(), 3, os.SEEK_HOLE))
"""
Under Solaris, the reply is 5, pointing to the end of the file.
Under current FreeBSD 9, it replies "3". In fact, it replies back current file offset.
This is wrong according to "lseek" man:
"""
[...]
 o If whence is SEEK_HOLE, the **offset of the start of the**
 **next hole greater than or equal to the supplied offset**
 **is returned**. The definition of a hole is provided near
 the end of the DESCRIPTION.
[...]
 A "hole" is defined as a contiguous range of bytes in a
 file, all having the value of zero, but not all zeros in a
 file are guaranteed to be represented as holes returned with
 SEEK_HOLE. Filesystems are allowed to expose ranges of zeros
 with SEEK_HOLE, but not required to. Applications can use
 SEEK_HOLE to optimise their behavior for ranges of zeros,
 but must not depend on it to find all such ranges in a file.
 **The existence of a hole at the end of every data region**
 **allows for easy programming and implies that a virtual hole**
 **exists at the end of the file.** Applications should use
 fpathconf(_PC_MIN_HOLE_SIZE) or pathconf(_PC_MIN_HOLE_SIZE)
 to determine if a filesystem supports SEEK_HOLE. See fpath-
 conf(2).
 **For filesystems that do not supply information about holes,
 the file will be represented as one entire data region.**
"""
So FreeBSD has two bugs:
1. It is giving an error if the filesystem doesn't support holes. The correct behavious SHOULD report a hole at the end of the file.
2. In a file without holes, on a filesystem supporting holes (ZFS), FreeBSD 9 is returning current file offset for SEEK_HOLE, instead of reporting offset = filesize. Consistent with the "virtual hole" at the end of the file.
koobs, can you report to FreeBSD guys?.
In the meantime we could apply a "SkipIf" to this test, to skio FreeBSD 9 (for now).
Ideas?