How do I make sure that Dropbox, when it's running on a system that was just restored from a backup (eg using timeshift or whatever), doesn't push old versions of files as though they're new modifications?
For example, let's say I have two computers running Dropbox:
and a file synced between them:
And then let's say I:
- make a backup of computer_two
using something like timeshift for example
which basically just uses rsync both to make a copy for backups, and to put everything back for restores
- modify file_X on computer_one
- restore computer_two to its previous state (ie, before file_X was modified)
In the past, in at least similar situations, I've had problems with Dropbox on the restored computer_two where it would try to push the older version of file_X (ie, from before it was modified) rewriting the newer version (on the Dropbox cloud and on computer_one), as though the restored, unmodified, older version of file_X was actually the *latest* new modification to file_X.
Obviously, I can avoid this problem by simply removing Dropbox from the restored computer_two and manually adding it back, but that involves having the restored computer_two download all the synced file from scratch.
And obviously, that's much slower and more annoying and non-ideal, but I don't want to risk messing around experimenting with any quicker ways, unless I can be confident I won't accidentally revert file_X to an out-of-date state.
--- As far as I can tell, relevant stuff might be contained in all of:
~/.dropbox/ ~/.dropbox-dist/ ~/Dropbox/
Is there just some config/cache file/directory in there I could simply delete? (and just exclude from my backups in the first place)
ie, the desired end result is that, when I first boot up the restored computer_two, and start Dropbox, it knows to only propagate state from the cloud *to* computer_two's Dropbox, and never *from* computer_two's Dropbox, until computer_two's Dropbox is up to date again.