I started off finding 'problems' in my code and tracked the issues to Dropbox and similar programs of its ilk (Google Drive, One Drive, etc.).
The issue comes when you open a file (usually with exclusive access) immediately after closing it after updating it. Other programs (Quicken comes to mind) also have poor interactions when this occurs.
The manifestation is that when you open the file for exclusive access (after it has been changed), Dropbox may already have control of the file, and the open will fail. The likelihood is 90+%. With Quicken, it is every time. It depends on the size of the file, and the delay between closing it and re-opening it. The time it takes Dropbox to send the file to the server is also part of the equation.
The key is to do one of the following: Wait for a sufficient amount of time before re-opening the file Wait for the file to be come available by retrying the open Pause the Dropbox (or similar) application
I have also seen this interaction when performing a compile, where the object folder is being monitored for changes. It is much more unlikely. Perhaps 1 in every 600 compile operations has an issue. As I say, it is rare.