[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:
If we add a second watcher on the Samba 4.4.9 share, we get this behavior:
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
In case you haven't, can you try with "kernel change notify = no"?
Probably should have mentioned I was doing the renames with an SMB client, not on the Samba host directly.
Had not tried that setting. The issue is not seen when "kernel change notify = no" set in smb.conf.
Not sure where that leaves this report.
Is it possible this is related to https://bugzilla.samba.org/show_bug.cgi?id=12756