On Fri, 5 Sept 2025 at 03:28, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Thu, Sep 04, 2025 at 01:26:36PM +0200, Miklos Szeredi wrote: > > On Wed, 3 Sept 2025 at 17:49, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > > > On Wed, Sep 03, 2025 at 11:55:25AM +0200, Miklos Szeredi wrote: > > > > > > Agree? > > > > > > I think we do, except maybe the difficult first point. :) > > > > Let's then defer the LOOKUPX thing ;) I'm fine with adding IMMUTABLE > > and APPEND to fuse_attr::flags. > > OK. Should I hide that behind the fuse mount having iomap turned on? > Or fc->is_local_fs == true? Or let any server set those bits? > > One thing occurred to me -- for a plain old fuse server that is the > client for some network filesystem, the other end might have its own > immutable/append bits, in which case we actually *do* want to let those > bits through from the FUSE_STATX replies. Right, as I said this might have worked without VFS help, but having it consistently in the VFS as well would be nicer. In that spirit, putting those bits in the inode is safe only in the local fs case, so I guess that's what we should do. And for consistency, in the local fs case inode->flags should be the authoritative source and all the userspace API's should be looking at that, instead of what the server sent in the IOCTL or STATX replies. Thanks, Miklos
