Re: Splicing to/from a tty

From: Al Viro
Date: Wed Jan 20 2021 - 22:21:30 EST


On Wed, Jan 20, 2021 at 05:04:17PM -0800, Linus Torvalds wrote:

> The whole point of O_APPEND is that the position shouldn't matter.
>
> And the whole point of "pwrite()" is that you specify a position.
>
> So the two just do not go together - although we may have legacy
> issues, of course.

Our pwrite(2):
BUGS
POSIX requires that opening a file with the O_APPEND flag
should have no effect on the location at which pwrite() writes
data. However, on Linux, if a file is opened with O_APPEND,
pwrite() appends data to the end of the file, regardless of
the value of offset.
POSIX pwrite(2):
The pwrite() function shall be equivalent to write(), except that
it writes into a given position and does not change the file offset
(regardless of whether O_APPEND is set). The first three arguments
to pwrite() are the same as write() with the addition of a fourth
argument offset for the desired position inside the file. An attempt
to perform a pwrite() on a file that is incapable of seeking shall
result in an error.

I don't believe that we could change behaviour of our pwrite(2) without
breaking userland, even if we wanted to. It's been that way since
2.1.60 when pwrite() had been first introduced - 23 years ago is more
than enough to have it cast in stone. We do allow pwrite(2) with O_APPEND
and on such descriptors it acts like write(2) on the same.

> Now, splice() is able to do *both* write() and pwrite(), because
> unlike pwrite() it doesn't take a "pos" argument, it takes a _pointer_
> to pos. So with a NULL pointer, it's like read/write, and with a
> non-NULL pointer it is like pread/pwrite.
>
> So I do think that "splice with non-NULL off_out and O_APPEND" should
> cause an error in general.

splice() triggers an error for seekable destination with O_APPEND and
with NULL off_out. Same for splice() to socket with
fcntl(sock_fd, F_SETFL, O_APPEND);
done first.

> Honestly, I don't think it's a huge deal. O_APPEND isn't that
> interesting, but I do hope that if we allow O_APPEND and a file
> position, then O_APPEND always overrides it.

It does, when it is allowed.