Mateusz Guzik wrote:
>On 9/27/20, Alan Somers wrote:
>> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen
>> wrote:
>>
>>>
>>> > I'll assume you are referring to the "flags" argument when you say
>>> "param" above.
>>>
>>> Correct, I was misremembering the man page.
>>>
>>> > However, since the Linux
On 9/27/20, Alan Somers wrote:
> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen
> wrote:
>
>>
>> > I'll assume you are referring to the "flags" argument when you say
>> "param" above.
>>
>> Correct, I was misremembering the man page.
>>
>> > However, since the Linux man page says it will return EI
On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen
wrote:
>
> > I'll assume you are referring to the "flags" argument when you say
> "param" above.
>
> Correct, I was misremembering the man page.
>
> > However, since the Linux man page says it will return EINVAL if
> > the "flags" argument is non-zero
On Sat, Sep 26, 2020 at 8:52 PM Rick Macklem wrote:
> Wall, Stephen wrote:
> > Could the as yet unused options param have a bit assigned to trigger the
> new
> > behavior? Inform the linux community of the addition and let them
> decide if they
> > would like to adopt it as well.
> I'll assume y
Wall, Stephen wrote:
> Could the as yet unused options param have a bit assigned to trigger the new
> behavior? Inform the linux community of the addition and let them decide if
> they
> would like to adopt it as well.
I'll assume you are referring to the "flags" argument when you say "param"
a
I know cross-posting is frowned upon, but I wanted everyone who might
like to comment to see this.
Currently copy_file_range(2) only supports regular files, which is compatible
with the Linux one, where EINVAL is returned when either file descriptor
refers to a non-regular file.
Alan Somers would
