|
|
|
|
|
|
by sintaxi
2326 days ago
|
|
|
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. https://news.ycombinator.com/item?id=12464901 |
|
|
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.
But really I have no idea.