When syncing files on Windows (possibly on other platforms as well) the file currently syncing is opened denying write access to other processes. This is ofcourse natural, but let me describe my use case and then explain my suggestion.
I have set up BT Sync on several computers and devices both to achieve a constant back up, but more importantly distributing my project files so I can (almost) immediatly go to another work place and access my updated files there. BT Sync is the only tool that has a fast enough indexing function to achieve that, that I have found. I have hundreds of thousands of files covered by BT Sync but still, changing a random file will almost immediatly sync it to my other work places. This is awesome and very unique.
My problem is that while BT Sync is working on a file, it is locked. So compiling my project will fail if BT Sync happens to be working on the .exe (or debug map files) of that specific project. As these files can be anywhere between 50 and 100 mb when compiling them with debug info (and I have some rather slow links on my network) this can be anoying, and I usually pause the sync (which will stop syncing the file, but annoyingly continuing to index and notify my of locked files).
My suggestion is to look into the possibility (and ofcourse implement it if possible) of creating a local copy of the file to sync BEFORE it is synched, and then read from the created local copy. That will make the locked time much shorter and allowing the user to keep on working on his or her project without interference from BT Sync.
The fact that it is not the absolutelly latest file beeing synced doesn't matter I think. BT Sync could abandon the sync if it detects a new version of the original file, or simply pick up the changes in the next indexing cycle.