forums.silverfrost.com

[wahorger]

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.

[wahorger]

John, yes, it works great! I have an upgraded account, so it saves the last 120 days of changes for me. That's source, command files, etc. Anything that is on the drive. I save the executables, objects, etc. on a different logical drive anyway so it doesn't clutter up my space, AND since it will upload a file when it changes (i.e. a re-link), it uses time and bandwidth fo larger files (like executables).

If I don't need it to be updating, I just tell it to pause syncing.

[mecej4]