It seems that when using change notify (internal only with no inotify
mechanism) the notification doesn't work on share directory path for
create and rename operations (and works only for delete).
It appears that when working on share directory, the add change notify
request receives the following path "/share_path/." and cuts off the
"\." at the path end. The notification request is saved with
But on notify_trigger (fro example when creating file_name),
notify_fname creates a full path: "/share_path/./file_name" and doesn't
cut off the prefix "./" of the relative file path. Then notify_trigger
searches for the relevant subscription "/share_path/." in the tdb file
and of course fails.
The attached patch solves the problem.
Software Engineer - Core Technologies
Created attachment 3746 [details]
Patch for 3.0.x.
Created attachment 3747 [details]
Patch for 3.0.x
> Great catch - thanks !
> I think we can do this without the strlen or tmp_path though, as
> we know we have a string of at least one character, so
> the statement :
> if (path == '.' && path == '/')
> will always be safe as the order of evauluation will be
> path first only followed by path if path == '.'.
> So the patch could be as simple as the attached. I'll
> apply (with git-author attribution of course).
Actually we should also do the same to the path
creation in change_notify_create(), to ensure
all the paths are correctly canonicalized - which
would make the canonicalization code inside
notify_add() able to be removed (but I'm going
to leave it for now for stability).
So the complete patch should be (IMHO) the
attached. Please test !
Created attachment 3748 [details]
Correct patch for 3.0.x.
Never mind, that change in change_notify_create()
would break the "./" removal logic in notify_add().
Here is the correct patch.
Fixed in all git branches.