We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Synchronizing encrypted files
Hi, here is a synchronization problem.
I have a list of files. Each is encrypted using a AES block cipher in CTR (counter) mode with its own password, a salt and an initialisation vector, where...
- 1: This sounds more like a product decision, so we can't offer a "right" answer. For comparison, Dropbox has to deal with essentially the same scenario. That is, when both the local and remote copies of a file have changed before the file could be synced. Dropbox creates "conflicted copies" in this case, in order to make sure neither version of the data is lost, and to let the user themselves decide which (or both or neither) to keep, since Dropbox can't know which one(s) they actually want.
2: Using the modified time isn't necessarily recommended for this, as clocks can differ. The Dropbox API offers two things you can use: a) the content hash, to confirm the exact data, and b) the file "rev". You can store the last known rev and compare it to the current remote rev. If the rev changed, you know that the content may have changed. If the rev hasn't changed, you know that the content did not change. The rev can't be locally computed though.
Greg-DB
Dropbox Staff
Dropbox Staff1: This sounds more like a product decision, so we can't offer a "right" answer. For comparison, Dropbox has to deal with essentially the same scenario. That is, when both the local and remote copies of a file have changed before the file could be synced. Dropbox creates "conflicted copies" in this case, in order to make sure neither version of the data is lost, and to let the user themselves decide which (or both or neither) to keep, since Dropbox can't know which one(s) they actually want.
2: Using the modified time isn't necessarily recommended for this, as clocks can differ. The Dropbox API offers two things you can use: a) the content hash, to confirm the exact data, and b) the file "rev". You can store the last known rev and compare it to the current remote rev. If the rev changed, you know that the content may have changed. If the rev hasn't changed, you know that the content did not change. The rev can't be locally computed though.
2: Using the modified time isn't necessarily recommended for this, as clocks can differ. The Dropbox API offers two things you can use: a) the content hash, to confirm the exact data, and b) the file "rev". You can store the last known rev and compare it to the current remote rev. If the rev changed, you know that the content may have changed. If the rev hasn't changed, you know that the content did not change. The rev can't be locally computed though.
Thanks very much for the clarification.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
