[Apologies in advance for being a Linux/Samba noob. We are primarily a MS shop but use Linux 3.10.102 running Samba 4.4.9 on a Synology Rackstation box. Hopefully this is enough info for someone more Samba-literate than us.]

We have multiple C# apps that use a System.IO.FileSystemWatcher to watch for file renames in a directory on a Samba share. We recently upgraded from Samba 3.x to 4.4.9 and have noticed a change in watcher notification behavior.

The typical behavior (for shares on Win servers, Samba 3.x, or Samba 4.4.9 with only 1 watcher) is to get 3 SMB events on a file rename: 
NOTIFY_ACTION_OLD_NAME
NOTIFY_ACTION_NEW_NAME
NOTIFY_ACTION_MODIFIED

If we add a second watcher on the Samba 4.4.9 share, we get this behavior:
NOTIFY_ACTION_OLD_NAME
NOTIFY_ACTION_NEW_NAME
NOTIFY_ACTION_NEW_NAME
NOTIFY_ACTION_MODIFIED

Notes:
1) Adding a third watcher to the Samba share does not produce an additional spurious NOTIFY_ACTION_NEW_NAME, we still get 4 notifications
2) When > 1 watcher, all watchers get the four events, not just the first or last watcher
3) We don't see this behavior with >1 watcher on a Windows share or Samba 3.x share.
4) These watchers are not using filters, ie they are watching for any changes on any file

The second NOTIFY_ACTION_NEW_NAME isn't paired with a NOTIFY_ACTION_OLD_NAME, so when this bubbled up and our app tried to access OldName of System.IO.RenamedEventArgs it was null and crashed the app. We've changed the apps to test the null case and handle this gracefully but this doesn't seem like the correct behavior for Samba.  

Steps to Reproduce:
1) Create a folder on a Samba 4.4.9 share and create a test file
2) Create an app to watch for file changes on the Samba share and report SMB events received
4) Rename the test file, you should see 3 smb events
5) Launch a second instance of the file change watch app (same client or diff, doesn't matter)
6) Rename the file again, you will get the 3 smb events plus an extra 
NOTIFY_ACTION_NEW_NAME