Real Time Sync not detecting changes recursively on NETWORK shares

Get help for specific problems
Posts: 4
Joined: 15 Apr 2019

djensen

Although I confirm RTS accurately detects changes in local hard drive directories recursively, RTS does not find changes in any NETWORK shared directory below the directory explicitly listed in the RTS watch list. For example if my watch list shows: "H:\" RTS dutifully detects changes at the H: level, but if I have a subdirectory (e.g. H:\temp), RTS does not detect any activity in the H:\temp directory. I want to help diagnose what is happening - so please let me know what I can do to provide more information, and although I'm pretty savy, please talk to me like a six year old so I can be sure I understand how to help. My company is huge with lots of software and hardware infrastructure - so I'm curious if anyone else has reported this and how they made it work! RTS+FFS *are* the solution for me - but I need it to run automagically lest I forget and wind up with two sets of unsynced file structures - yikes! Thanks in advance for your help! Doug
Posts: 4
Joined: 15 Apr 2019

djensen

Sorry my omission: Adding that my situation applies to RTS version 10.11 - but have tried earlier revisions several times in the last few years with the same results - non recursive detection on network shares.
User avatar
Site Admin
Posts: 7042
Joined: 9 Dec 2007

Zenju

RTS just calls ReadDirectoryChangesW with bWatchSubtree set to "true". If this is not working, I'd have to pass the blame on to the network drivers (maybe they're not implementing SMB 3.0 but an earlier version?).
Posts: 4
Joined: 15 Apr 2019

djensen

Thank you for the peek under the hood. Is there a way a mere mortal can determine the SMB version our company is using? I can imagine trying to ask that of our IT Borg, but I'm out of goats required as an offering...Usually when I try to ask 'networky' questions like that I get great sucking of wind sounds and thrown into the queue of questions no one is capable or wanting to answer...it's not like I'm asking them to provide the meaning of life (everyone knows 42 is the answer to that...duh...)
User avatar
Posts: 2251
Joined: 22 Aug 2012

Plerry

See here for a potential way to check the SMB version being used between client and server.
Posts: 4
Joined: 15 Apr 2019

djensen

Thank you for the help. The Get returns Dialects 3.0.2 or 3.0.0 for the different shares RTS is trying to monitor. Any other possibilities folks? I really want to take advantage of your well executed tools! Would there be some odd interaction with the IdleTime? Would a long (60 seconds) or short (1second) be something to consider? I would expect this is just your polling rate so I wouldn't expect any difference in changing this length - but again - treat me as 'clueless'!
User avatar
Posts: 2251
Joined: 22 Aug 2012

Plerry

No, the Idle time in RTS is the time the monitored location(s) need to be idle (i.e.: have no activity/changes) after a change (or the last change) has been detected, before launching the specified application, normally FFS).
This is intended to prevent (already) launching FFS while the monitored location is still (frequently) changing, e.g. by copying files to it.