Thread (2 messages) flat view 2 messages, 2 authors, 2025-08-04

Re: [fuse-devel] copy_file_range return value on FUSE

From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2025-08-04 13:30:41
Also in: linux-fsdevel, lkml

On Mon, 4 Aug 2025 at 11:42, Florian Weimer via fuse-devel
[off-list ref] wrote:
The FUSE protocol uses struct fuse_write_out to convey the return value
of copy_file_range, which is restricted to uint32_t.  But the
copy_file_range interface supports a 64-bit copy operation.  Given that
copy_file_range is expected to clone huge files, large copies are not
unexpected, so this appears to be a real limitation.
That's a nasty oversight.  Fixing with a new FUSE_COPY_FILE_RANGE_64
op, fallback to the legacy FUSE_COPY_FILE_RANGE.
There is another wrinkle: we'd need to check if the process runs in
32-bit compat mode, and reject size_t arguments larger than INT_MAX in
this case (with EOVERFLOW presumably).  But perhaps this should be
handled on the kernel side?  Currently, this doesn't seem to happen, and
we can get copy_file_range results in the in-band error range.
Applications have no way to disambiguate this.
That's not fuse specific, right?

Thanks,
Miklos
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help