On Fri, Feb 25, 2022 at 7:49 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Fri, Feb 25, 2022 at 08:23:20AM -0500, Vivek Goyal wrote: > > What about local events. I am assuming you want to supress local events > > and only deliver remote events. Because having both local and remote > > events delivered at the same time will be just confusing at best. > > This paragraph confuses me. If I'm writing, for example, a file manager > and I want it to update its display automatically when another task alters > the contents of a directory, I don't care whether the modification was > done locally or remotely. > > If I understand the SMB protocol correctly, it allows the client to take > out a lease on a directory and not send its modifications back to the > server until the client chooses to (or the server breaks the lease). > So you wouldn't get any remote notifications because the client hasn't > told the server. Directory leases would be broken by file create so the more important question is what happens when client 1 has a change notification on writes to files in a directory then client 2 opens a file in the same directory and is granted a file lease and starts writing to the file (which means the writes could get cached). This is probably a minor point because when writes get flushed from client 2, client 1 (and any others with notifications requested) will get notified of the event (changes to files in a directory that they are watching). Local applications watching a file on a network or cluster mount in Linux (just as is the case with Windows, Macs etc.) should be able to be notified of local (cached) writes to a remote file or remote writes to the file from another client. I don't think the change is large, and there was an earlier version of a patch circulated for this -- Thanks, Steve
