On Wed 08-01-20 12:25:55, Amir Goldstein wrote: > > > What I like about the fact that users don't need to choose between > > > 'parent fid' and 'object fid' is that it makes some hard questions go away: > > > 1. How are "self" events reported? simple - just with 'object id' > > > 2. How are events on disconnected dentries reported? simple - just > > > with 'object id' > > > 3. How are events on the root of the watch reported? same answer > > > > > > Did you write 'directory fid' as opposed to 'parent fid' for a reason? > > > Was it your intention to imply that events on directories (e.g. > > > open/close/attrib) are > > > never reported with 'parent fid' , 'name in directory'? > > > > Yes, that was what I thought. > > > > > I see no functional problem with making that distinction between directory and > > > non-directory, but I have a feeling that 'parent fid', 'name in > > > directory', 'object id', > > > regardless of dir/non-dir is going to be easier to document and less confusing > > > for users to understand, so this is my preference. > > > > Understood. The reason why I decided like this is that for a directory, > > the parent may be actually on a different filesystem (so generating fid > > will be more difficult) and also that what you get from dentry->d_parent > > need not be the dir through which you actually reached the directory (think > > of bind mounts) which could be a bit confusing. So I have no problem with > > always providing 'parent fid' if we can give good answers to these > > questions... > > > > Actually, my current code in branch fanotify_name already takes care of > some of those cases and it is rather easy to deal with the bind mount case > if path is available: > > if (path && path->mnt->mnt_root != dentry) > mnt = real_mount(path->mnt); > > /* Not reporting parent fid + name for fs root, bind mount root and > disconnected dentry */ > if (!IS_ROOT(dentry) && (!path || mnt)) > marks_mask |= fsnotify_watches_children( > dentry->d_sb->s_fsnotify_mask); > if (mnt) > marks_mask |= fsnotify_watches_children( > mnt->mnt_fsnotify_mask); > > Note that a non-dir can also be bind mounted, so the concern you raised is > actually not limited to directories. > It is true that with the code above, FAN_ATTRIB and FAN_MODIFY (w/o path) > could still be reported to sb mark with the parent/name under the bind mount, > but that is not wrong at all IMO - I would say that is the expected behavior for > a filesystem mark. Yes, good points. > IOW, the answer to your question, phrased in man page terminology is: > (parent fid + name) information is not guarantied to be available except for > FAN_DIR_MODIFY, but it may be available as extra info in addition to object fid > for events that are possible on child. > > For example, an application relying on (parent fid + name) information for > FAN_MODIFY (e.g. for remote mirror) simply cannot get this information when > nfsd opens a file with a disconnected dentry and writes to it. And another good point. > TBH, I am not convinced myself that reporting (parent fid + name) for > directories > is indeed easier to document/implement than treating directories different that > non-directories, but I am going to try and implement it this way and prepare a > draft man page update to see how it looks - I may yet change my mind after > going through this process... Ok, fair enough. I guess you've convinced me that both 'parent fid' and 'directory fid' approaches are somewhat messy so whatever ends up being simplier / easier to understand is good :). Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
