On 07/06/19 09:04, Paul Eggert wrote: > Although I agree with both of Bruno's reasons, on further thought it makes > sense > for Gnulib to provide a stub instead of an emulation for this particular > function. > > The primary use for copy_file_range is to copy files more efficiently than a > read+write loop. However, the read+write loop will typically still be needed > anyway, to handle non-regular files, copying across file system boundaries, > or > even copying regular input files whose size shrinks while copying as > copy_file_range (mistakenly, in my view) reports an error if asked to copy > past > end of file. > > Because of all these special cases, a reliable use of copy_file_ranges will > need > to be followed by a read+write loop that handles the special cases where > copy_file_ranges fails. And this read+write loop will work even if > copy_file_range is a stub that always fails. So there's no practical need to > emulate copy_file_range. > > For an example of the code I'm thinking of, see the call to copy_file_range > that > I recently introduced into GNU Emacs: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=486a81f387bb59b2fbbc6aff7b41adbe1621394e > > Because of the above, I simplified Gnulib's implementation of copy_file_range > by > installing the attached. If we find a good use for copy_file_range that could > take advantage of an emulator rather than a stub, we can revert this.
I definitely agree with this decision. I also see that yesterday glibc also reverted to a stub rather than emulation: https://sourceware.org/ml/libc-alpha/2019-06/msg00873.html cheers, Pádraig