Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation

[Horst Birthelmer <horst@birthelmer.de>]

On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
> On 1/9/26 19:29, Amir Goldstein wrote:
> > On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
> >>
> >>
> >>
> >> On 1/9/26 16:37, Miklos Szeredi wrote:
> >>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
> >>>
> >>>> What about FUSE_CREATE? FUSE_TMPFILE?
> >>>
> >>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
> >>>
> >>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
> >>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
> >>>
> > 
> > I thought that the idea of FUSE_CREATE is that it is atomic_open()
> > is it not?
> > If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
> > it won't be atomic on the server, would it?
> 
> Horst just posted the libfuse PR for compounds
> https://github.com/libfuse/libfuse/pull/1418
> 
> You can make it atomic on the libfuse side with the compound
> implementation. I.e. you have the option leave it to libfuse to handle
> compound by compound as individual requests, or you handle the compound
> yourself as one request.
> 
> I think we need to create an example with self handling of the compound,
> even if it is just to ensure that we didn't miss anything in design.

I actually do have an example that would be suitable.
I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.

> 
> 
> Thanks,
> Bernd

Cheers,
Horst