Date: Wed, 20 Sep 2023 15:52:26 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273962] copy_file_range does not work on shared memory objects Message-ID: <bug-273962-227-tL4K4BZiVn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273962-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962 --- Comment #2 from David Chisnall <theraven@FreeBSD.org> --- (In reply to Rick Macklem from comment #1) > The title uses "file" which I think of as "regular file", On *NIX, everything is a file. I found it very surprising that it didn't work with shared memory objects. On Linux (where this call originated), shared memory objects are files in a special memory filesystem and so the line is especially blurry. I don't believe the Linux implementation has such a limitation: it falls back to the equivalent of a read and write loop in the kernel if the fast paths are not supported). As a user, it's very surprising that a pair of file descriptors that work with lseek, read, and write, do not work with `copy_file_range`. It's made worse by the fact that `EINVAL` covers a variety of errors and so writing fallback code for when the file descriptor provided to an API does not work with this function cannot unambiguously detect that the reason for the failure was a file descriptor for which this is not supported. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273962-227-tL4K4BZiVn>