We’re Still Here to Help (Even Over the Holidays!) - find out 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. ...
Nancy
Dropbox Community Moderator
Dropbox Community ModeratorHi 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.
Hello Nancy! Here's an explanation and Events logs from two recent runs -- one successful, one failed. Both done on the same machine, the only one connected to that Dropbox account, so there's no interference from outside. (Every other machine and account we've tested with has consistently been working fine.)
The Events logs were too big for one screenshot, so I've put them into Word files with annotations:
[removed per Community Guidelines]
In both cases, we were testing with a three-level folder structure; we encrypted the parent folder, then shared the second-level folder (which re-encrypted it with its own keys), then shared the third-level folder (ditto). In the failure case, it's the third-level folder which gets the conflicted copy.
The encryption software encrypts the filenames, of course; in this case, the user had a folder "Level 2A" containing a subfolder "Level 3A". They encrypted "Level 2A", meaning that all its files were encrypted and renamed -- subfolder "Level 3A" became "qaKSYdh....empfs". Dropbox showed these changes as the old names being deleted and the new ones added... so far, so normal.
Then when the user shares the encrypted subfolder "Level 3A" separately -- the software then re-encrypts its contents under its own keys separate from its parent "Level 2A". What the encryption software does is:
* Change the (encrypted) name of each file inside "qaKSYdh....empfs" to use the new keys
* Change "qaKSYdh....empfs"' name back to "Level 3A"
Re-encrypt each file's contents inside Level 3A with the new keys
It happens in that order. But Dropbox handles it in this order:
* ""qaKSYdh....empfs"" and its contents are all deleted
* The new folder is added as "Level 3A (OrexTest3's conflicted copy)", with the files inside re-uploaded under their *old* encrypted names
* Then the files inside are re-deleted (still using their *old* names)...
* ...and re-added (using their new names)
This is weird on multiple levels -- first, it seems to think that the old "Level 3A" folder still exists, even though it was explicitly deleted before any of this. Also, it re-uploads the supposedly-conflicted "Level 3A" with the *old* file names, before replacing them with the new ones, despite the fact that the files' names were changed before the folder ones!
Frankly, I'm baffled, and any clue to why it thinks there's a conflict would be a big help.
Oh, and a footnote -- the only difference between the two runs is the name and number of files. The successful run had two tiny text files in each folder, the failed one had three large files in the megabyte range in each one. That suggests a timing issue in how long it takes to re-encrypt and upload... but we still get the failures even if we leave it for several minutes between steps in the re-encryption.
Further addition -- here's the folder activity on the restored just-plain-Level-3A folder.
Since there are multiple deleted-and-added files with those names in the event log, I can't immediately find which one I should restore and check its version history -- can you recommend a way to work that out? Or should I just get the tester to re-run it with unique filenames?
- Nancy
Thanks for this info, Jon! One more thing I may suggest; can you pause the syncing of the Dropbox app, encrypt the folder, and then resume syncing again? Do the conflicts occur, if you do this instead?
