* Miklos Szeredi: > On Mon, 4 Aug 2025 at 11:42, Florian Weimer via fuse-devel > <fuse-devel@xxxxxxxxxxxxxxxxxxxxx> 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. Or adding a capability flag to switch from struct fuse_write_out to something that uses an uint64_t value. One complication: The struct fuse_write_out layout is too close to a potential 64-bit version of it on little-endian systems, so that proper testing might be difficult with the obvious approach. >> 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? In-kernel file systems can check if the request originated from a compat process, using in_compat_syscall. I don't think that's possible over FUSE. Thanks, Florian
