On Wed, 13 Aug 2025 at 19:09, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> 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.
It would still require a feature flag and negotiation via FUSE_INIT.
I find adding a new op cleaner.
> > - err = -EOPNOTSUPP;
> > + if (fc->no_copy_file_range_64) {
>
> Maybe clearer here to do the if check on the args.opcode? Then this
> could just be
> if (args.opcode == FUSE_COPY_FILE_RANGE) {
Okay.
> > +/* For FUSE_COPY_FILE_RANGE_64 */
> > +struct fuse_copy_file_range_out {
>
> imo having the 64 in the struct name more explicitly makes it clearer
> to the server which one they're supposed to use, eg struct
> fuse_copy_file_range64_out
Makes sense.
Thanks,
Miklos
