On Thu, Dec 10, 2020 at 2:23 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Thu, Dec 10, 2020 at 1:43 PM Jan Kara <jack@xxxxxxx> wrote: > > > > Hi Amir! > > > > On Wed 09-12-20 21:14:53, Amir Goldstein wrote: > > > I have a use case with a listener that uses FAN_REPORT_FID mode. > > > (fid is an index to a db). > > > Most of the time fid can be resolved to the path and that is sufficient. > > > If it cannot, the file will be detected by a later dir scan. > > > > > > I find that with most of the events this use case can handle the events > > > efficiently without the name info except for FAN_CREATE. > > > > > > For files, with most applications, FAN_CREATE will be followed by > > > some other event with the file fid, but it is not guaranteed. > > > For dirs, a single FAN_CREATE event is more common. > > > > > > I was thinking that a FAN_CREATE_SELF event could be useful in some > > > cases, but I don't think it is a must for closing functional gaps. > > > For example, another group could be used with FAN_REPORT_DFID_NAME > > > to listen on FAN_CREATE events only, or on FAN_CREATE (without name) > > > the dir can be scanned, but it is not ideal. > > > > > > Before composing a patch I wanted to ask your opinion on the > > > FAN_CREATE_SELF event. Do you have any thoughts on this? > > > > Well, generating FAN_CREATE_SELF event is kind of odd because you have no > > mark placed on the inode which is being created. So it would seem more > > logical to me that dirent events - create, move, delete - could provide you > > with a FID of object that is affected by the operation (i.e., where DFID + > > name takes you). That would have to be another event info type. > > FAN_CREATE_SELF makes sense for a filesystem mark. I forgot to > mention that in the description of my use case. > It also makes sense to API IMO because of symmetry with delete and move self > vs. a completely new type of event. Scratch that please. I misread your reply and I was thinking about it the wrong way. I agree with you that FAN_CREATE_SELF makes little or no sense. One option is adding another info type as you wrote, with yet another FAN_REPORT_XXX flag I presume. Another option is adding another event type (as I thought you had suggested). Something like FAN_LINK, for when an inode is linked into the namespace but from the perspective of the inode as opposed to the perspective of the parent dir where the inode is being linked. We could match it with FAN_UNLINK, or interpret FAN_LINK as any sort of change with linkage of the inode to the namespace (create/delete/rename) maybe name the event FAN_LINKS. Obviously, FAN_EVENT_INFO_TYPE_FID would be that of the (un)linked inode and FAN_EVENT_INFO_TYPE_DFID would be that of the parent. Apart from being able to learn the fid of a new object appearing in the filesystem or a new child or a watched parent, watcher can be watching a file and be notified when that file has been unlinked from the namespace, even if the file still has open references delaying the report of FAN_DELETE_SELF. Thoughts? Amir.
