cp: Expect EINTR while copying

[des]

Summary

Both copy_file_range() and copy_fallback() can be interrupted before
they have read anything at all, in which case they return -1 and set
errno to EINTR. If that happens, we should retry, not fail.

MFC after: 1 week
PR: 293028

[des]

hang on, that won't actually work, brb

[asomers]

This is probably correct. However, I'd like to see two other things:

• A reproduction case
• An audit of the rest of the base system for other utilities that make the same mistake, like install(1).

[cracauer]

In D55167#1261329, @asomers wrote:

This is probably correct. However, I'd like to see two other things:

• A reproduction case
• An audit of the rest of the base system for other utilities that make the same mistake, like install(1).

The reproducing case is timing dependent. I came up with the discrepancy when a user on the forums interrupted a cp operation with a du and cp bailed out.

I will troll the base system for similar cases.

[asomers]

In D55167#1261330, @cracauer wrote:

The reproducing case is timing dependent. I came up with the discrepancy when a user on the forums interrupted a cp operation with a du and cp bailed out.

Do you at least know what fuse file system he was using, and what options it was mounted with?

[des]

fix loop termination

[cracauer]

In D55167#1261331, @asomers wrote:

In D55167#1261330, @cracauer wrote:

The reproducing case is timing dependent. I came up with the discrepancy when a user on the forums interrupted a cp operation with a du and cp bailed out.

Do you at least know what fuse file system he was using, and what options it was mounted with?

NTFS. I just asked the user for flags.

[asomers]

In D55167#1261343, @cracauer wrote:

In D55167#1261331, @asomers wrote:

In D55167#1261330, @cracauer wrote:

The reproducing case is timing dependent. I came up with the discrepancy when a user on the forums interrupted a cp operation with a du and cp bailed out.

Do you at least know what fuse file system he was using, and what options it was mounted with?

NTFS. I just asked the user for flags.

NTFS uses libfuse-2. That version doesn't even support FUSE_COPY_FILE_RANGE. So my guess is that vn_copy_file_range did one read and then one write. The write went through fuse_vnop_write, but then it blocked, because the FUSE daemon was processing other commands. So no FUSE_WRITE operation ever got sent to userspace. Then something sent a signal to the process. So the fusefs module abandoned the write operation, returning EINTR, and vn_copy_file_range faithfully returned it to userspace.

[des]

simplify