Hi 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 "/share_path" path. 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. <<change_notify_on_volume_root.patch>> Thanks, Dina Fine Software Engineer - Core Technologies Exanet Ltd. dina@exanet.com, Evgeny.Popovich@exanet.com
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[0] == '.' && path[1] == '/') > > will always be safe as the order of evauluation will be > path[0] first only followed by path[1] if path[0] == '.'. > > > 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. Jeremy.