amir73il
FAN_REPORT_COOKIE and FAN_REPORT_FILENAME
Didn't find FAN_REPORT_COOKIE or FAN _REPORT_FILENAME in the kernel, just wondering if this is a feature you are working on, if so at what time we could expect it to be available upstream.
Those are from patches that I carry on top of upstreamed patches, see: https://github.com/amir73il/linux/commits/fanotify_filename I am not sure if they will even be upstreamed. I think it is more likely that I will ditch them at some point or replace them with some other improvement. Why do you ask? Do you have any interest in those?
Yeah I wanted to use fsnotifty to invalidate some cache on a webserver, but then i would need the filenames. And getting the filenames from the inode number does not seem to be optimal.
Well, if you think that FAN_REPORT_FILENAME is useful to the community as is, I suggest that you claim your case on [email protected]. I have already discussed the feature with fsnotify maintainer and he had some good arguments against it. I also had some alternative proposals, but a serious discussion would have to be held on the mailing list.
I'm curious, why do you say that getting the filenames from inode number (more accurately from file handle) seems "not optimal"? I think quite the contrary - storing fid in kernel queue is much more optimal then storing variable length filenames. I think what is missing in current API is only a cookie that could be used to connect events on parent (e.g. delete, move_from, move_to) carrying parent fid, with events on child (e.g. delete_self,move_self) carrying the child fid.
Can you list specific concerns so I can address them?
First off, thank you for taking the time to answer my questions.
I'm curious, why do you say that getting the filenames from inode number (more accurately from file handle) seems "not optimal"?
I was thinking of traversing through the entire file system and comparing inode numbers (which I read someone recommended using if you only had the inode number).
To be honest I didn't know that you could find the filename using the file_struct. I managed to get it using open_by_handle_at(2), and readlink(3P), but is there a way to do this without opening a file descriptor?
Can you list specific concerns so I can address them?
The only concern I have now is that opening a file descriptor every time an event takes place might be a little slow.
The proper way to do this is not by open_by_handle_at(2) but by name_to_handle_at(2)
If the webserver uses name_to_handle_at(2) and statsfs(2) to create the file id and index the cache entry with that file id, then you don't need the filename at all. All you need to do when you get an event is to figure out if the file id is related to one of the cache entries, because file id does not change throughout the lifetime of a file, but getting a file's path is forever a racy business.
An example of how that can work is here: https://github.com/amir73il/inotify-tools/commits/fanotify_dirent