iCloud is not involved with Dropbox. DropBox Storage is a cloud.
I’ve been acquainted with the structure of DropBox (DB) for many years. Let’s start with the high-level view.
There are four components of DB, the cloud storage database, a local work area in macOS, the macOS DB application, and the DB website.
The Dropbox.com website (the cloud site) does the usual things - sets up an account, prepares the cloud storage and Oops areas,
and downloads the DropBox application.
When the DropBox application is installed, it sets up the local work area storage (the Apple File Provider ~/Library/CloudStorage) and the Oops areas - a mirror of the DB cloud structure.
The work area storage contains a simple file structure of folders and files and cannot be found in Finder. The head of this structure is the DropBox icon inserted into the User folder which shows up in the Apple Finder. Clicking the icon opens DBFinder which looks exactly like Apple Finder. (Calling this another SSD drive would be incorrect.) Here the user copies/moves folders and files between the two Finder structures.
In to early DB days, the DB work area was in the System folder, and the mirror image was that folders and files were synced and identical. This meant that there were multiple copies of the same file - a minimum of 4 (cloud/work areas/two Oops areas). One more if the original file was from macOS, and 2 x the number of times a file was opened and closed during the thirty-day Oops area copies.
It was no wonder there were many unhappy users about how much macOS disk space was being gobbled up.
There’s more to write here but I wanted to get this out first.
E.g., The Oops is a 30-day retention area for Restoring previous versions of a file. i.e. an archival area. …
Before getting into syncing, I need to be clear about “online/offline”. It’s probably the worst pair of words one could choose. The DropBox the cloud storage database is always online except when selecting Sleep or Shut Down. The start-up file contains the file that starts up the DropBox app which immediately looks for work to do, i.e. connected and online. Always, unless the user suspends and restarts syncing manually.
The underlying method employed by DB is called “store and forward”. This method solves problems like this. You’ve finished your wellness exam and the doctor sets up authorizations for pharmacy, blood test, and an x-ray exam. The goal is the make sure that individual is registered in each department to avoid waiting to be registered at each department before they can arrive to get treatment in any order of arrival. And one of the department computers may be down.
The “store and forward” design consists of two forms - hub and spoke or husband wheel. “Hub and wheel” is where everyone is connected to everyone. This is a huge mess when you want to add another member of the wheel (and beyond this discussion).
The hub (the DropBox cloub) becomes the focus of hub and spoke design and is under very heavy activity. For example, if DB had 1,000,000 accounts, with 5 employees sharing all files, and its 5 PM Friday night in a single time zone, and 5 million users closed their application after submitting 1 update or new file, the download would be 5M syncs and 20M uploads to sync the other 4 devices on the account. A perhaps extreme example but mathematically correct. In this “hub and spoke” example, there is no “I” or “me”. It’s an environment of queuing requests. It is a fantasy to expect a half-second response time.
Syncing
Many conditions prevent syncing. As an example, The Fri sync request (the updated file is moved into a DBFinder folder) may be ignored if the hub cannot respond to start or finish a download request because the security protocol requires that a machine must be shut down before leaving the office. That sync will begin syncing Monday when the computer is started up. The file will be stale if looked at over the weekend.
Stay tuned. Mike
To be continued.
Mike