On Wed 15-03-17 16:34:11, Amir Goldstein wrote:
> On Wed, Mar 15, 2017 at 4:05 PM, Jan Kara <j...@suse.cz> 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 <j...@suse.com>
SUSE Labs, CR
