[Dropbox] InSync forgot to rename conflicting folders back

Bugs and issues Linux
#1

Hello again,

As I continue to dump more files into Dropbox and sync them with InSync to various systems, I’m finding new ways to confuse and break InSync in strange and interesting ways.

As a part of consolidation and moving to cloud process, I’ve found out that I have newer versions of some folders on a macOS system, which is interfacing Dropbox via the official client. To compare and consolidate, I do the following (consider we’re working on folder folder-name).

  1. Rename folder-name to folder-name-old in Dropbox folder.
  2. Move in new folder as folder-name.
  3. Consolidate and do magic.
  4. Remove folder-name-old.

During this mayhem, InSync catches a glimpse of what’s happening on another (Linux) system, understands what’s happening correctly (honestly kudos!), and since it had no time to rename folder-name to folder-name-old, syncs the new folder as folder-name (2), and links it to folder-name (the new one) in its internal database.

Then, when folder-name-old is deleted, it removes folder-name, leaving folder-name (2) behind. However, it never renames folder-name (2) back to folder name.

Now I have some folder-name (2) folders inside an out-of-tree synced folder, on a secondary drive, which point to proper, new folders on the Dropbox side.

The question is “How can I fix this?” This is a 40K file folder, synced out of tree, at base level. So, I need to unsync and sync it back ideally. But it’s a lot of small files. It’ll take hours. It’ll hammer the Dropbox API too.

What’s the best way to correct the folder names as it should?

BTW, I’m not mad. I’m just confused. :slight_smile:

#2

Let me check this out with our engineers so we can assess the situation further and provide some possible solutions to rectify the issue! :slight_smile:

Thank you as always for walking us through the case in detail.

1 Like
#3

Hi Mia,

Thanks a lot. No problems. I just want to add that the phenomenon can be reproduced too when InSync Linux client is offline. I edited some more files in the same big folder (in the same manner) yesterday, and when I turned my Linux system on, it synced and created a couple more folder-name (2)folders.

So, the issue can be perfectly reproducible, even if the InSync arrives to the scene later.

Cheers,

H.

#4

Hey @bayindirh!

Our engineers wants to know what happens if you rename any of those affected folders locally?

If you could also send your latest logs.db and out.txt to support@insynchq.com following this reproducible incident, that would be greatly appreciated :slight_smile:

#5

Hi @mia,

You probably have a mail. :slight_smile:

For the testing, I’ll create a small lab under a VM with a spare Dropbox account I have, since I can’t risk the files inside my cloud storage. It won’t take long.

Thanks for understanding,

Cheers,

H.

1 Like
#6

@bayindirh I did get a mail, thank you!

Re: testing – sure thing :slight_smile:

#7