svn commit: r365643 - head/bin/cp

[Rick Macklem]

Alan Somers wrote:
>On Fri, Sep 11, 2020 at 3:52 PM Rick Macklem <rmacklem at uoguelph.ca<mailto:rmacklem at uoguelph.ca>> wrote:
>Konstantin Belousov wrote:
>>On Fri, Sep 11, 2020 at 08:49:36PM +0000, Alan Somers 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"
>>
>>Devices are seekable.
>>
>>The reason for EINVAL is that vn_copy_file_range() checks that both in and out
>>vnodes are VREG.  For devfs, they are VCHR.
>
>I coded the syscall to the Linux man page, which states that EINVAL is returned
>if either fd does not refer to a regular file.
>Having said that, I do not recall testing the VCHR case under Linux. (ie. It might
>actually work and the man page turns out to be incorrect?)
>
>I will test this case under Linux when I get home next week, rick
I'll admit I haven't tested this in Linux to see if they do return EINVAL.

>Since there's no standard, I think it's fine for us to support devfs if possible.
1 - I think this is a good question for a mailing list like freebsd-current at .
2 - I see Linux as the de-facto standard these days and consider POSIX no
      longer relevant, but that's just mho.
3 - For NFSv4.2, the Copy operation will fail for non-regular files, so if you
      do this, you will need to handle the fall-back to using the generic code.
      (Should be doable, but you need to be aware of this case.)

Having said the above, it is up to the "collective" and not me and, as such,
I suggest #1, to see whether others think doing a non-Linux compatible
version makes sense for FreeBSD?

rick