Here "sync" means what Dropbox says it means. The answers to your questions are well defined in their software, even if to some other software, they might be different.
I wish the term didn't exist, and apps/clients/... would copy or even just load or show things, and if you want to "sync", then rsync with clear source and destination.
The source and destination is always clear. It's to the server and from the server. Dropbox uses a star topology, not P2P.
You'd get the same result if you used rsync with source and destination, if you passed --delete, which is equivalent to what Dropbox does.
"The source and destination is always clear. It's to the server and from the server."
That's exactly what I mean by not clear: to the server and from the server are the exact opposites. So if something is not present on one side, it can do two things to make both sides equal: it can delete it from the one side, or it can copy it to the other side. If all it has is a "sync" button, not a "sync to server" or "sync from server" button, it's not clear what it will do.
Something that deletes files shouldn't be called sync, but should clearly be marked as a delete operation. And deleting something from one location should not have the surprise effect of deleting it on other locations too, unless it's called "remove everywhere".
if something is not present on one side, it can do two things to make both sides equal: it can delete it from the one side, or it can copy it to the other side. If all it has is a "sync" button, not a "sync to server" or "sync from server" button, it's not clear what it will do.
It's only not clear because you're using "sync" in an abstract sense. In Dropbox, it is clear: if the side had the file and it disappeared, it's considered a deletion. If it never had it, it's assumed it should receive a copy.
There's no ambiguity in the context of Dropbox, even if there is in the term "sync" generally.
Something that deletes files shouldn't be called sync, but should clearly be marked as a delete operation.
Why? A deletion is just another action comparable to adding a file, moving it, etc. Sure it may lose data, but if you edit a file, replace the contents and copy it to the other side with overwrite, it can lose data too. That's why Dropbox provides a 30-day backup feature.
File sync with multiple devices is fraught with danger. Remember the old 'briefcase' on the Windows desktop? There's just no way to distinguish 'I don't want this file on this device' from "I don't want this file on any device'".
I think "recency" is a better mental model than star topology for how Dropbox works.
The authoritative source of the data is whichever endpoint has been modified most recently. If you delete a file on one machine, it's then deleted on the server, and then on other machines. The file is gone everywhere.
If you then go to one of those machines and restore the file from a local backup, the file is re-uploaded to the server, and then each machine will re-download it. The file is back everywhere.
If you log into the web interface and delete it there, each of the machines will delete it as well. The file is gone everywhere.
At any point the controlling view of the data is the one that was most recently updated.
I wish the term didn't exist, and apps/clients/... would copy or even just load or show things, and if you want to "sync", then rsync with clear source and destination.
The source and destination is always clear. It's to the server and from the server. Dropbox uses a star topology, not P2P.
You'd get the same result if you used rsync with source and destination, if you passed --delete, which is equivalent to what Dropbox does.