Most people in that thread are just complaining of high disk usage without specifying where access occurs.
Then page 3 has the following user report:
> I'm running Windows 10 and my Dropbox is located on my E drive (E:\Dropbox). I also notice high disk activity. However when I look in Resource Monitor I noticed that the high activity generated by Dropbox.exe is on the C drive (not E).
To which an employee says the reason is that dropbox is installed on C:.
> Although you have your Dropbox folder on your E: drive, the application is still installed on your C: drive, so that’s why you’re seeing the activity there.
Sorry, I did a poor job explaining. The smoking gun is CPU usage not file system activity. Perhaps you know more about this and can explain it to me. If I copy files from one place on my system that is outside of my Dropbox folder to any other location that is also outside of my Dropbox folder, how is it even possible for the Dropbox client to consume CPU resources if it isn't monitoring files outside of the Dropbox folder?
Here is link showing more people reporting the same problem. Files being copied from one part of the file system to another and the Dropbox client consumes 60%-100% CPU. I cant even comprehend how that is possible.
> how is it even possible for the Dropbox client to consume CPU resources if it isn't monitoring files outside of the Dropbox folder?
I did not debug this or look at anything, so I can't tell you.
One plausible explanation is they are effectively polling Dropbox folder instead of blocking until actual changes occurr. So maybe that hogs CPU scanning the Dropbox folder at inappropriate times, meaning that other activity on the machine has to compete for CPU time and lock acquisitions with unrelated but very noisy requests from the Dropbox client.
The fact that some users say that adjusting ACLs might get their client "unstuck" would fit this theory. Maybe they had a bug that generates noisy scans on the disk when they get "access denied" in an unexpected place.
