Real Time Sync not detecting changes recursively on NETWORK shares
- Posts: 4
- Joined: 15 Apr 2019
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
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.
- Site Admin
- Posts: 7285
- Joined: 9 Dec 2007
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
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...)
- Posts: 2524
- Joined: 22 Aug 2012
See here for a potential way to check the SMB version being used between client and server.
- Posts: 4
- Joined: 15 Apr 2019
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'!
- Posts: 2524
- Joined: 22 Aug 2012
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.
This is intended to prevent (already) launching FFS while the monitored location is still (frequently) changing, e.g. by copying files to it.