bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem

[Moyard John]

GPFS maintainers give me the answer including manpage close(2) : nothing will 
be done.
On the web, same problems has been identified  for ZFS or perhaps NFS v4 ? :
 https://utcc.utoronto.ca/~cks/space/blog/linux/GrepBinaryFileReason
https://github.com/zfsonlinux/zfs/issues/6050
https://lists.gnu.org/archive/html/bug-grep/2012-07/msg00022.html
I will not file a bug on each file system maintainers : I should obtain the 
same answer.
Or perhaps I will obtain an extract of manpage lseek(2), i.e. 
http://man7.org/linux/man-pages/man2/lseek.2.html :
     However, a filesystem is not obliged to report holes, so
    these operations are not a guaranteed mechanism for mapping the
    storage space actually allocated to a file
It's not a bug in file system.

So, is-it possible for you to modify something about the way to test binary 
file ?

john

-----Message d'origine-----
De : Paul Eggert [mailto:address@hidden 
Envoyé : jeudi 13 juillet 2017 22:44
À : Moyard John; Eric Blake; address@hidden
Objet : Re: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem

On 07/13/2017 02:13 AM, Moyard John wrote:
> That's why I was asking about another way to identify a binary file instead 
> using 'seek(SEEK_HOLE)' : do you think that it could possible?

If there is a reasonable (i.e., cheap) way for grep to determine that SEEK_HOLE 
is buggy for the current file, I suppose grep could do that. 
Do you know of any such method?

Really, the bug here is in the file system, not in grep. Have you filed a bug 
with the GPFS maintainers?