svn commit: r365643 - head/bin/cp

[Kyle Evans]

On Tue, Sep 22, 2020 at 3:54 PM Mateusz Guzik <mjguzik at gmail.com> wrote:
> On 9/22/20, Alan Somers <asomers at freebsd.org> wrote:
> > On Tue, Sep 22, 2020 at 2:48 PM Kyle Evans <kevans at freebsd.org> wrote:
> >
> >> On Fri, Sep 11, 2020 at 3:49 PM Alan Somers <asomers at freebsd.org> wrote:
> >> >
> >> > Author: asomers
> >> > Date: Fri Sep 11 20:49:36 2020
> >> > New Revision: 365643
> >> > URL: https://svnweb.freebsd.org/changeset/base/365643
> >> >
> >> > Log:
> >> >   cp: fall back to read/write if copy_file_range fails
> >> >
> >> >   Even though copy_file_range has a file-system agnostic version, it
> >> still
> >> >   fails on devfs (perhaps because the file descriptor is non-seekable?)
> >> In
> >> >   that case, fallback to old-fashioned read/write. Fixes
> >> >   "cp /dev/null /tmp/null"
> >> >
> >>
> >> Hi,
> >>
> >> Any objection to adding a quick UPDATING entry for this? I'm seeing
> >> occasional reports of this breakage as recent as today on IRC from
> >> folks that were a little bit thrown off by this because it throws up
> >> fairly far into the build and looks like a stand build regression
> >> instead of a cp regression.
> >>
> >> Thanks,
> >>
> >> Kyle Evans
> >>
> >
> > No objection.  Can you suggest the proper wording?
>
> Can we instead add a workaround to the build tree?
>
> Where is cp /dev/null coming from anyway? Perhaps this can be patched
> to touch the target file.
>

I'll look into why stand's doing it this way, but the workaround is a
bit heavy-handed than an advisory to effectively do the same; you'd
have to pick what ends up being a huge range of revisions based on
__FreeBSD_version to decide on bootstrapping a cp that gets used
instead.