We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Conflicted copy on a folder?
OK, I understand the principle of what creates a conflicted copy with a file, which has been updated while another user (or the same user's account on another machine) has also updated it remotely. But what gets a *folder* marked as a conflicted copy?
I'm seeing an odd situation: when the encryption software we're using encrypts a folder, it changes its name -- and on one user's machine, Dropbox quickly adds the "(conflicted copy)" postscript to the folder. But as far as we know, this test user is only using their account on one machine, and not sharing the folder with anyone -- so what could it be comparing it with to decide it's a conflict?
(Bit more detail: we generally see this on a nested folder. Say the user has /TopFolder/Subfolder, and encrypts /TopFolder -- this renames the subfolder to /TopFolder/5y798k45asgu2 or something. But if they then choose to share the subfolder separately, our software renames it back to /TopFolder/Subfolder -- at which point, within a matter of seconds, Dropbox marks it as a conflicted copy. Even if the folder was only first created on this one machine minutes ago, and it's not syncing to any other machines. So what's being flagged?)
- Walter
Dropbox Staff
HI there Jon B.1 - sorry to hear about this.
Could you have a look at the events page and let us know what you find about this specific conflicted folder?
Also, have you tried restoring a sample file from inside the folder and check its version history for more information about what might be happening?
Keep us posted!
Hi Walter! Here's some updates.
First of all, I'd like to point out that the problem appears to be timing-related -- we see it regularly on this one machine when encrypting/decrypting a large structure of folder and files in the multi-megabyte range. When doing it with a small structure with only a couple of text files, even on that machine, we don't see it.
As for the events log -- I'll see if I can get some complete screenshots of the relevant events, but to summarise: normally all that shows up in the Dropbox server events log for one of these re-encryptions is adds and deletions. (In fact, none of the files or folders are actually being added or deleted -- just re-encrypted in place and then renamed.) But in the failure case, we see the following sequence of events:
* On the first encryption, Subfolder 1 is "deleted" and its encrypted version GSj84f7wnI4059.empfs is "added" (along with its encrypted files)
* When re-encrypting the encrypted subfolder, its files are "deleted" and then "added" with their new names. These first two steps happen the same in normal cases and failure cases.
* GSj84f7wnI4059.empfs is "deleted"... but when it's re-added, it's not re-added as "Subfolder1", but "Subfolder1 (OrexTest3's conflicted copy)". Despite the fact that the old Subfolder1 was "deleted" some minutes earlier.
So that points the finger straight at the Dropbox client trying to reconcile the "new" folder with the "deleted" version of it from before... but where's it getting the idea that the "old folder", which the client and server acknowledged was deleted a couple of minutes ago, still exists?
- Nancy
Hi Jon B.1! I hope it’s OK if I jump in here.
It sounds like that’s the case, indeed; for some reason, Dropbox still “sees” the old folder, when the new one is generated, which creates this conflict.
If you could send us a couple of screenshots of what appears on your Events page, that’d be really helpful.
Let me know when you’re ready.
