On Wed 15-03-17 16:34:11, Amir Goldstein wrote: > On Wed, Mar 15, 2017 at 4:05 PM, Jan Kara <jack@xxxxxxx> wrote: > >> So the string fields in my proposal are optional. > >> userspace opts-in to get them by specifying the FAN_EVENT_INFO_NAME flag: > >> > >> fanotify_init(FAN_CLOEXEC | FAN_CLASS_NOTIF | > >> FAN_EVENT_INFO_PARENT | FAN_EVENT_INFO_NAME, > >> > >> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events > >> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name. > > > > So when thinking about this again, I'm again concerned that the names need > > not tell userspace what it thinks. I know we already discussed this but > > in our last discussion I think I forgot to point out that inotify directory > > events (and fanotify would be the same AFAICT) may come out of order compared > > to real filesystem changes. E.g. sequence: > > > > Task 1 Task 2 > > > > mv a b > > mv b c > > > > may come out of inotify as: > > > > IN_MOVED_FROM "b" COOKIE 1 > > IN_MOVED_TO "c" COOKIE 1 > > IN_MOVED_FROM "a" COOKIE 2 > > IN_MOVED_TO "b" COOKIE 2 > > > > Really? How come? > > fsnotify_move() inside vfs_rename() is serialized with lock_rename() Sorry, I got confused by the unlocking in vfs_rename() however that unlocks only the moved file / directory but not the directory in which the rename is happening. Taking my objection back. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
