On Thu, 22 Oct 2026, Jimmy Zuber wrote: > On Wed, 21 Oct 2026, NeilBrown wrote: > > This all looks like a reasonably sensible design. As permission checking > > happens in the client, not on the server, it is appropriate that > > FUSE_OPEN_ATOMIC only opens the file if it actually created it. > > So it doesn't make sense to implement O_TRUNC. > > > > However the code seems to suggest that the server might open the file if > > it was found to already exist. In that case, were does the permission > > check happen... > > > > Maybe I need a more explicit statement of what FUSE_OPEN_ATOMIC is meant > > to do in the various cases. Or maybe I just don't know enough about > > fuse. > > FUSE_OPEN_ATOMIC will open an existing regular file unless O_TRUNC is > specified. If the server opens an existing file, the kernel will perform a > permission check after the reply (do_open() calls may_open()). If that > permission check fails, we will release the file. This matches other file > systems that support atomic_open(), such as ceph, where a file can be opened > before a kernel check is performed. Servers that don't want this should just > return the entry only to have the kernel check permissions and open. I'll try > to make the expected behavior of FUSE_OPEN_ATOMIC implementations more clear > in v2.
It seems a little odd performing the "open" before any permission check, but I can see how it might work, and as you say the server an refuse if it has reason too. Thanks for the clarification. NeilBrown > > > There is work underway to support O_CREAT|O_DIRECTORY so that a > > directory can be created and opened in a single operation. Would it > > make sense to include this in FUSE_OPEN_ATOMIC ?? > > Oh thanks for the heads up. This would be a nice fit. If that series is > accepted I can update this one accordingly. That said, even with that series > it might be nice to have an init flag in case implementations want to > selectively support atomic file but not directory open/create (ENOSYS is too > coarse grained). >
