Bug 5908 - Samba 3.0.32 - internal change notify on share directory fails.
Summary: Samba 3.0.32 - internal change notify on share directory fails.
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.9
Hardware: Other Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2008-11-18 14:23 UTC by Jeremy Allison
Modified: 2008-11-18 14:49 UTC (History)
0 users

See Also:

Patch for 3.0.x. (685 bytes, patch)
2008-11-18 14:24 UTC, Jeremy Allison
no flags Details
Patch for 3.0.x (1.03 KB, patch)
2008-11-18 14:25 UTC, Jeremy Allison
no flags Details
Correct patch for 3.0.x. (433 bytes, patch)
2008-11-18 14:39 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2008-11-18 14:23:20 UTC

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.
Dina Fine
Software Engineer - Core Technologies
Exanet Ltd.

dina@exanet.com, Evgeny.Popovich@exanet.com
Comment 1 Jeremy Allison 2008-11-18 14:24:05 UTC
Created attachment 3746 [details]
Patch for 3.0.x.
Comment 2 Jeremy Allison 2008-11-18 14:25:22 UTC
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 !
Comment 3 Jeremy Allison 2008-11-18 14:39:50 UTC
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.
Comment 4 Jeremy Allison 2008-11-18 14:49:15 UTC
Fixed in all git branches.