On Wed, Aug 13, 2025 at 12:21 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>
> * Joanne Koong:
>
> > On Wed, Aug 13, 2025 at 8:24 AM Miklos Szeredi <mszeredi@xxxxxxxxxx> 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 size copies and there's no reason why copies
> >> should be limited to 32-bit.
> >>
> >> Introduce a new op COPY_FILE_RANGE_64, which is identical, except the
> >> number of bytes copied is returned in a 64-bit value.
> >>
> >> If the fuse server does not support COPY_FILE_RANGE_64, fall back to
> >> COPY_FILE_RANGE.
> >
> > Is it unacceptable to add a union in struct fuse_write_out that
> > accepts a uint64_t bytes_copied?
> > struct fuse_write_out {
> > union {
> > struct {
> > uint32_t size;
> > uint32_t padding;
> > };
> > uint64_t bytes_copied;
> > };
> > };
> >
> > Maybe a little ugly but that seems backwards-compatible to me and
> > would prevent needing a new FUSE_COPY_FILE_RANGE64.
>
> Even with a capability flag, it encourages the presence of bugs that
> manifest only on big-endian systems.
>
Interesting, can you explain how? size would always be accessed
directly through write_out->size (instead of extracted from the upper
32 bits of bytes_copied), so wouldn't the compiler handle the correct
memory access?
Thanks,
Joanne
> Thanks,
> Florian
>
