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:egg...@cs.ucla.edu] Envoyé : jeudi 13 juillet 2017 22:44 À : Moyard John; Eric Blake; 27...@debbugs.gnu.org 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?
