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/> References: <bug-273962-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273962 --- 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 w= ork 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 w= ith lseek, read, and write, do not work with `copy_file_range`. It's made wors= e by the fact that `EINVAL` covers a variety of errors and so writing fallback c= ode 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273962-227-tL4K4BZiVn>