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. BTW, what's the problem with just using FAN_REPORT_DFID_NAME? You don't want to pay the cost of looking up & copying DFID+name instead of FID for cases you don't care about? Is there such a significant difference? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
