bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Mike Gilbert]

On Fri, Jun 02, 2023 at 05:31:50PM +0100, Pádraig Brady wrote:
> I'm not sure it was working correctly before 9.3 either.
> Before 9.3 we would have switched from copy_file_range() to read()/write()
> upon receiving the EINVAL, which might have worked, but also I'm not sure
> the file offsets would be correct in that case. Could you show the output 
> with:
> 
> diff --git a/src/copy.c b/src/copy.c
> index 0dd059d2e..35c54b905 100644
> --- a/src/copy.c
> +++ b/src/copy.c
> @@ -363,7 +363,16 @@ sparse_copy (int src_fd, int dest_fd, char **abuf, 
> size_t buf_size,
>                  edge case where the file is made immutable after creating,
>                  in which case the (more accurate) error is still shown.  */
>               if (*total_n_read == 0 && is_CLONENOTSUP (errno))
> -              break;
> +              {
> +                if (*total_n_read != 0)
> +                  {
> +                    off_t clone_read_offset = lseek (src_fd, 0, SEEK_CUR);
> +                    off_t clone_write_offset = lseek (dest_fd, 0, SEEK_CUR);
> +                    printf ("switching to standard copy at :%"PRIdMAX" 
> read=%"PRIdMAX" write=%"PRIdMAX"\n",
> +                            *total_n_read, clone_read_offset, 
> clone_write_offset);
> +                  }
> +                break;
> +              }
> 
>               /* ENOENT was seen sometimes across CIFS shares, resulting in
>                  no data being copied, but subsequent standard copies 
> succeed.  */

I don't think this patch will do anything useful: *total_n_read cannot be 0
and not 0 simultaneously, so the new block of code will never be
executed. Maybe you meant to insert this block somewhere else?