we are seeing a dichotomy between the current posix definition of a hole:
easy to generated by
loop {
seek
write
}
but not discernable by the api other than guessing sequences of 0 bytes
statements about how ast works are w.r.t. current posix
the (posix) proposed { SEEK_HOLE SEEK_DATA } take care of discernment
by offering a way to differentiate hole vs 0-byte
I believe most of ast can become proposed-posix holey with
a few modifications to sfmove() (pax would have to change to include
sparse format extensions and use the read side { SEEK_HOLE SEEK_DATA }
logic of sfmove() on archive write )
*if*
is it still the case with { SEEK_HOLE SEEK_DATA } that holes are created
by using standard lseek() ops to lseek(2) ahead between sequential write(2)s?
one other question
is this a valid check for a sparse file on fd open for read:
lseek(fd, SEEK_HOLE, 0) >= 0
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
