About Brian B.39

I agree, my impression is near instantaneous (checking every couple seconds or so?) and I have taken issue in the past with the amount of traffic generated by the dropbox clients (many people in a large office with a mediocre WAN link is a recipe for a significant network percentage used up with checks for updates). Your question broken up:   Q: What happens if I open a file while my internet is down? A: You are offline so standard dropbox rules apply with conflicted copies.     Q:  Or the website? A:  I am not proposing getting rid of the current Colaboration interface which is what is being used when you edit online. An exclusion filter allowing the locking mechanism on every file except those covered by the current collaboration app plugin (the badge and online editing).   Q: Or on a mobile device? A:   The mobile app can also execute the same file locking logic on all but filtered collaboration file types. https://www.dropbox.com/help/desktop-web/edit-microsoft-office-files-mobile     ... View more

My mistake, you are correct.  So that initial server check is the real issue. Do you know what the standard timeout is for the Dropbox client to check for file updates on the server? 4 times per second 4 times per minute? ... View more

Thanks for the insight, Personally I do think it is quite possible to ensure 99.9% certainty. Every time a File open occurs right now, Dropbox always checks to ensure that the file is the most up to date version before allowing it to be opened.   This means that as soon as that requiest is made and recieved at the Dropbox server, thier server code checks the properties on the file and retrieves the file version and compares it to the Users local copy. If they don't match then the reply to the query initiates the download of the delta (the differences between version), Once the delta download is complete, the local dropbox client writes the new sector to the old sector and updates the file system, then the program is allowed to open the file on the local computer for editing. The Dropbox client then sends a broadcast on the local file system to let any other local dropbox clients know that it has the new version of the file for local network updates.  All of that is happening right now.   Since the server is already checking and comparing the file version on the server copy of the file, and the client is already checking the local file properties to get the version information, it is simply not communicating the file lock status.   There will be no collisions at the server in 99.9% of cases. The only issue is    The only real issue comes from One individual working offline. I think the answer to that is... you are working offline, expect a conflicted copy and having to merge (If it is an Office doc then that can be delit with through the badge merge).   Two individuals opening the same file within 1 or two seconds of each other will be the 0.01% of cases. There will almost always be an individual who won the locked case. For that 0.01% of cases, the answer is equally straight forward though, after writing to the File Lock parameter, wait 0.1 seconds and then check the file lock again to make sure you own it and a state issue hasn't allowd another thread to over-write your lock or vise versa.   That take care of the state issues. As for multiple server farms and the replication time, every company gets the option to set the preferred data farm location. That way any data synced to another region always has lower priority.   On the client side if a file lock is lost, a big notification appears as a final safeguard.   That is My 2 cents. ... View more