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. > 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).
