is 1000001 a hole? (note that I am assuming the '0' is a byte of 0, not a bit)
how many 0's need to be in place before it should be identified as a hole?
what if the source is on 4192 byte sector media and the destination is on 512 byte sector media and a string of 1M zeros starts at an offset of 1024 into the file? does the hole start at 1K (where the zeros start and space could be saved on the 512 byte sector media), or at 4K where the source may have a hole? what if the source is a raid array where holes can only really be useful if punched in blocks of 64K*#drives?
I think the process of 'SEEK_HOLE' is better than getting a dump of how the file happens to be allocated at the moment, but it seems like this is too big a question to just overload into a single flag.
Since software would have to be modified to use it anyway, it seems like it may be better to have a seek_hole() function rather than flag on the existing lseek so that you could tell seek_hole() what you consider a hole.
I see the following valid definitions of holes as obvious
1. if it's a hole at the time of the seek
2. if it could be a hole at the time of the seek (taking into account the filesystem and device holding the file)
3. #2 with an automatic 'if you could punch a hole here, do so' flag
4. any string of X sequential bytes of 0 aligned on a multiple of Y bytes
5. #3 but with the definition that represents the 'sector size' so X == Y and it only needs to be specified once.
I could see all of these being useful in different situations.