[root@cent-57 bin]#  ./smbtorture //xx.xx.xx.xxx/share1  -T samba3 smb2.notify.rec -U <domain>/administrator%password
smbtorture 4.1.0
Using seed 1370521584
time: 2013-06-06 05:26:24.255776
test: rec
time: 2013-06-06 05:26:24.257085
TESTING CHANGE NOTIFY WITH RECURSION
time: 2013-06-06 05:26:25.529447
failure: rec [
(../source4/torture/smb2/notify.c:627) wrong value for notify.smb2.out.num_changes  0xb should be 0x9
]

As part of the test, client has registered for completion filter FILE_NOTIFY_CHANGE_NAME|FILE_NOTIFY_CHANGE_ATTRIBUTES|FILE_NOTIFY_CHANGE_CREATION and on file renames, server is sending 2 NOTIFY_ACTION_MODIFIED events along other 9 events. Hence the test is failing with receiving of wrong number of events.

Where as raw.notify.recursive (SMB1) similar test expects 11 events instead of 9.

we could see the following piece of code in notify_rename() which is responsible for sending the MODIFIED events on file rename with above mentioned completion filter.
 /* this is a strange one. w2k3 gives an additional event for
           CHANGE_ATTRIBUTES and CHANGE_CREATION on the new file when renaming
           files, but not directories */
        if (!is_dir) {
                notify_fname(conn, NOTIFY_ACTION_MODIFIED,
                             FILE_NOTIFY_CHANGE_ATTRIBUTES
                             |FILE_NOTIFY_CHANGE_CREATION,
                             smb_fname_dst->base_name);
        }

And I guess this code is added to handle the SMB1 case where we send the extra notifications.

Bacause of the same code, smb2 torture test(notify.rec) is failing as the test is not expecting the MODIFIED events.

Initially we thought of making adding one more check for protocol for allowing these notifications. Like..
           if (!is_dir && !(conn->sconn->using_smb2)) {
                           ...
           }

With this change server was able to send modified notifications to smb1 clients but not to smb1.

But later we figured out that with these changes smb2.notify.mask-change hanging because mask-change again expects the modified notifications on file rename with completion filter of FILE_NOTIFY_CHANGE_ATTRIBUTES.

In brief these are the observations.

1.raw.notify.recursion: Expects NOTIFY_ACTION_MODIFIED events on file rename.
2.smb2.notify.rec: not expecting NOTIFY_ACTION_MODIFIED events on file rename.
3.smb2.notify.mask-change: Expects NOTIFY_ACTION_MODIFIED events on file rename.

Windows(win2k8) is working fine(as torture expects) in all the three scenarios.