[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    [cifs-protocol] Getting SMB2 windows client to respond to notify event.
From:       Peter VAN OUDENAREN via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date:       2017-01-17 11:13:06
Message-ID: CALZq3DnVrbCWy+VfooAtHuWWoLCGQGerONHwktD-S287qJrNxQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I'm working on a server instance that requires Windows explorer and OSX  to
respond to notify events. The implementation works with OSX, minus a small
delay but not Windows.

I've picked over the packet flow between my implementation and Windows10
carefully versus the flow between Samba and Win10, and I can see only
slight differences. The packets I send for async notify responses with
STATUS pending, cancels and completion look correct.

The symptom is that Windows receives my properly formatted async notify
response packet but does not respond with any listing requests or re-arming
of the notify, I only see TCP keepalives. I think Windows may be processing
the messages because F5 refresh seems more likely to trigger activity after
receipt of a notify message.

I don't have oplocks enabled but it doesn't seem to change the behavior if
I grant oplocks.

I also noticed one peculiarity, Windows doesn't request a batch oplock on
the root of the share like it does against Samba but it does request them
in lower folders.

Some differences I see with the Samba packet flow are that I don't queue
changes and never respond synchronously so  "ls >a1.txt" will generate only
one async completion message and not respond synchronously with file
modified immediately afterwards.

That shouldn't matter with delete but in the process of writing this email
I convince myself to try leaving inotify armed and queuing events in
anticipation of a request next, to see if that helps.

Any suggestions ?


Peter

[Attachment #5 (text/html)]

<div dir="ltr"><div>I&#39;m working on a server instance that requires Windows \
explorer and OSX   to respond to notify events. The implementation works with OSX, \
minus a small delay but not Windows.</div><div><br></div><div>I&#39;ve picked over \
the packet flow between my implementation and Windows10 carefully versus the flow \
between Samba and Win10, and I can see only slight differences. The packets I send \
for async notify responses with STATUS pending, cancels and completion look correct.  \
</div><div><br></div><div>The symptom is that Windows receives my properly formatted \
async notify response packet but does not respond with any listing requests or \
re-arming of the notify, I only see TCP keepalives. I think Windows may be processing \
the messages because F5 refresh seems more likely to trigger activity after receipt \
of a notify message.</div><div><br></div><div>I don&#39;t have oplocks enabled but it \
doesn&#39;t seem to change the behavior if I grant oplocks.  \
</div><div><br></div><div>I also noticed one peculiarity, Windows doesn&#39;t request \
a batch oplock on the root of the share like it does against Samba but it does \
request them in lower folders.</div><div><br></div><div>Some differences I see with \
the Samba packet flow are that I don&#39;t queue changes and never respond \
synchronously so   &quot;ls &gt;a1.txt&quot; will generate only one async completion \
message and not respond synchronously with file modified immediately afterwards.  \
</div><div><br></div><div>That shouldn&#39;t matter with delete but in the process of \
writing this email I convince myself to try leaving inotify armed and queuing events \
in anticipation of a request next, to see if that helps.</div><div><br></div><div>Any \
suggestions ?</div><div><br></div><div><br></div><div>Peter</div><div><br></div><div><br></div></div>




_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic