Pádraig Brady <[email protected]> writes:
> I was debugging a change in coreutils 9.8 and noticed that fadvise was
> being passed OFF_T_MAX to indicate to apply advice to end of file.
>
> This struck me as a bit unusual and coreutils <= 9.7 used 0 to do the same
> thing.
> It seems to me like 0 may be treated specially or more efficiently in more
> cases?
>
> How about the following to go back to 0 meaning, to end of file?
>
> cheers,
> Padraig
>
> diff --git a/src/copy-file-data.c b/src/copy-file-data.c
> index 1eefd3071..c3abe41e2 100644
> --- a/src/copy-file-data.c
> +++ b/src/copy-file-data.c
> @@ -538,7 +538,7 @@ copy_file_data (int ifd, struct stat const *ist, off_t
> ipos, char const *iname,
> /* Don't bother calling fadvise for small copies, as it is not
> likely to help performance and might even hurt it. */
> if (IO_BUFSIZE < ibytes)
> - fdadvise (ifd, ipos, ibytes <= OFF_T_MAX - ipos ? ibytes : 0,
> + fdadvise (ifd, ipos, ibytes < OFF_T_MAX - ipos ? ibytes : 0,
> FADVISE_SEQUENTIAL);
>
> /* If not making a sparse file, try to use a more-efficient
Your change seems to match the expectations of POSIX [1]:
If len is zero, all data from offset to the largest possible value
of the file offset for that file shall be specified.
And the Linux man pages [2]:
or until the end of the file if size is 0
Whether or not it causes issues, I am not sure.
Collin
[1]
https://pubs.opengroup.org/onlinepubs/9799919799/functions/posix_fadvise.html
[2] https://www.man7.org/linux/man-pages/man2/posix_fadvise.2.html
