Conflicted copy on a folder?

[Jon B.1]

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]

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! 

[Jon B.1]

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.

[Jon B.1]

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.

[Jon B.1]

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.

[Jon B.1]

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?

[Jon B.1]

We'll try that!  FWIW, we've now seen the problem on a second machine (a macOS one), so this isn't down to an individual machine's configuration.  OTOH, we've seen this work successfully on a bunch of other machines with no problems, so it's not univeral.

[Jon B.1]

* universal