Error - This Folder Cannot Be Added To Sync. It Contains A Folder That Is Already Syncing.

[dhanger]

Devices:

 

Android KK

Win7 64 PC

 

I get the error under the following scenario:

 

Create backup for Pictures (camera) on Android, linking to a subfolder under My Pictures on the PC called 'dan's cell'.

 

Afterwards, on the PC, I try to add folder My Pictures for general snycing, but I get the error and can't setup My Pictures for syncing, apparently because I have the already existing Android backup to a subfolder (My Pictures\dan's cell).

 

Is this the way it's supposed to work? I can kinda, sorta see how trying to do this this may set up some kind of problem, but I'm not seeing how. I don't really understand why this should be a problem; if My Pictures on the PC is linked to other devices, then to my limited understanding it seems that it's only going to sync the 'dan's cell' folder along with all the rest without any conflicts. The only potential problem could be with the original Android with the camera backup, but with selective sync active I don't see the conflict. What am I not seeing here?

 

It appears that I am required to link the camera backup to some location outside the main My Pictures folder, but this disrupts the organization, requiring me to make a secondary movement of the backup files to My Pictures for the images I wish to keep. Not a big deal, really, but I was a little surprised by this error.

 

Thanks,

Dan

[jbr]

I'm encountering the same error, and agree that it doesn't entirely make sense. Here is my scenario:

 

I've got 2 NAS backing each other up (essentially each device is both a local data server and an offsite backup for my household and a family member's household). There are two main directories, one for me and one for the family member. Each directory is divided into documents, music, videos, and pictures. In order to sync, I select the parent folder on the target peer, and it syncs to the subfolder that corresponds to the source. I also anticipate creating a sync for my cell phone photo gallery identical to what Dan described, and I agree that it seems unnecessary to change the overall folder schema to accommodate this quirk.

 

Any solutions, or at least a workaround that won't result in ridiculous numbers of folders?

[RomanZ]

@all

The one folder being synced in another folder already synced is allowed only if both folders have read-write key. If any has RO key, BTSync won't allow you to add such folder - so it is design of application.

[jbr]

@all

The one folder being synced in another folder already synced is allowed only if both folders have read-write key. If any has RO key, BTSync won't allow you to add such folder - so it is design of application.

 

Thanks for the clarification. Do you happen to know why it is this way? I suppose I could make mine all read/write, but since my main purpose is off-site backup, I'm concerned this would expose me to a higher risk of data loss.

[jmvp]

Sorry but I find this explanation as confusing as it is clarifying.

 

I'm getting the error message, too.

 

My setup is "Android" syncing to "laptop#1." Now I want to sync from "laptop#1" to "3rd machine." I get the error message, presumably because "Android" is sending pictures to "laptop#1" (C:/...docs/pics) and I want to sync "laptop#1"(C:/...docs) to "3rd machine." ("Android" was set up to sync to "laptop#1" first.)

 

According to my understanding of your post, I need to put two R-W keys on both folders in "laptop#1."

 

Correct me if I'm wrong, but I can't find a way to issue R-W keys from the Android device to "laptop#1."  <-- right? One of these keys has to come from "Android" and I don't see how to issue that key.

 

OR: Are you saying I should issue R-W keys to "3rd machine" for a backup of "Android" on "laptop#1"???  (And this would be even though "3rd machine" is only ever to keep a copy of "Android" and never to write back to "laptop#1" (C:/...docs/pics) because it will never generate content for that folder???)

[danhunsaker]

Let's say you have your folders set up like this:

 

My Pictures (Source [RW])

|-- A Folder

|-- Dan's Cell (Backup [RO])

|-- Another Folder

|-- Dan's Tablet (2-way [RW])

 

My Pictures is a share created on your computer, so by nature has the read-write key.  Dan's Cell was created on a cell phone, and is intended only to back up photos taken on the phone, so this computer only has the read-only key.  Dan's Tablet, meanwhile, was created on the tablet, but is meant to be a 2-way sync, so photos can be shared from the tablet to this computer, but also from this computer to the tablet.

 

Here's where the trouble comes in.  BTSync has no way of knowing, when you create a new share, which key you're going to use on other computers/devices.  So it has to assume the share will be used in the most permissive mode - that is, read-write.  If it were to sync in a file from another device that belongs in the Dan's Cell folder, that new file couldn't ever be synced to the rest of the peers for that share.  Similarly, changes to existing files couldn't be synced either.  Without a way to determine which version of a file to keep, BTSync would end up not knowing how to proceed.

 

There are a number of potential ways around this, but each is a hack.  The only real solution is to prohibit creating shares on parent folders of read-only shares.  Unless we could somehow create a share that doesn't generate a read-write key, which will never allow syncing files in from other peers.  A "seed-only" share, as it were.  That would resolve any issues.  Until then, though, this is what we have.

[jmvp]

danhunsaker:

 

Thank you for the greater detail.

 

If I wanted to use BTSync to mirror data across multiple (non-mobile) machines, then I take it you would recommend using R-W keys on all of them.

 

Frankly I have found the distinction between R-W keys and R-O keys somewhat obscure: Wouldn't having a R-W key on one machine be the same as having both machines sync across using R-O?

 

What use, then, the R-O key?

[GreatMarko]

Frankly I have found the distinction between R-W keys and R-O keys somewhat obscure: Wouldn't having a R-W key on one machine be the same as having both machines sync across using R-O?

 

What use, then, the R-O key?

 

Two RO nodes in isolation wouldn't sync.

 

A RO node is one where any changes to files on that node are ignored, and won't propagate to other devices.

For more information, please see: What is a key and how does it work

 

If I wanted to use BTSync to mirror data across multiple (non-mobile) machines, then I take it you would recommend using R-W keys on all of them.

Yes, if you want to "mirror", you'd need to use RW keys - so that changes made on either will propagate to the other.

[danhunsaker]

The RO key is used when you don't want changes to sync back to the source. For example, if you're backing up data, you don't want the backup to change the data on the device you're backing up. Perhaps a better example, if you want to distribute files to other people, you may not want them to be able to make changes to those files, and then have those changes sync to everyone else in the swarm. So you'd give them RO keys, to prevent their changes from being synced back to the rest of the swarm.

You *might* be able to use RO keys to sync a given folder in two directions, but that increases the number of keys used, and conflicts become a lot harder to resolve. Not to mention the increased traffic from "Oh, new file! Sync it to the other guy!" going *both* directions, because at that point each sync has no idea who actually created the file and who already has it. RW keys are immensely more efficient for these purposes.

Encryption keys are even more complicated. They work the same as RO keys, except the data stays encrypted on disk. That means you can *only* access that data over the swarm that synced it to the disk in the first place. It also, however, ensures the data can't be accessed by untrusted parties with access to the storage system, meaning it's a secure backup even when used on an insecure storage. Not entirely sure if encryption keys are supported outside the API, yet, though, so you may not need to consider them for a while.

At any rate, I wouldn't recommend the two-RO approach to two-way syncing. It would end up causing more problems than it would solve, most of them involving inefficiency of the file transfer, but with a healthy side of conflicting versions never resolving themselves. Create sync shares on the machine with the master copy, use RW keys on machines where you want changes to sync back to the master, RO keys on machines where you don't want changes synced back to anyone, and encryption keys where you don't want changes synced back and also don't want your data to be readable outside the swarm.

[jmvp]

@GreatMarko @danhunsaker,

 

Thank you very much - this thread has greatly increased my understanding of the nature of keys and how collisions occur. I guess I'll need to rethink and then rearrange my "syncing architecture" to get my machines set up in a more intelligent way.

 

- jmvp