Test Idea:nested shares


Recommended Posts

This is an interesting idea, although, it could just be done through two sync'd folders. I'd like this option, although, not really prioritized over anything else. Also, let me just confirm?

Computer A & B recursively have:-

\Share\

However, computer C only has access (recursively) to:-

\Share\Apple\

So, if A or B update anything other than \Share\Apple -R, then, nothing happens to C, however, it is synced to A/B, however, if computer A/B or C sync to:-

\Share\Apple

Then all three get updated?

Link to comment
Share on other sites

This is an interesting idea, although, it could just be done through two sync'd folders. I'd like this option, although, not really prioritized over anything else. Also, let me just confirm?

Computer A & B recursively have:-

\Share\

However, computer C only has access (recursively) to:-

\Share\Apple\

So, if A or B update anything other than \Share\Apple -R, then, nothing happens to C, however, it is synced to A/B, however, if computer A/B or C sync to:-

\Share\Apple

Then all three get updated?

Exactly.

And it can be done using .syncignore and two (in this example) shares if you don't want to wait for an update.

Link to comment
Share on other sites

As I read more I have another question about this. Does this same current limitation occur when using a read only share?

For example, if I sync the parent directory from machine1 to machine2 as read only (this is stricly for a backup purpose) can I still NOT share subfolders to a third machine?

Sorry if I'm asking a lot of questions. This software is truly amazing and I can't stop thinking about it.

Link to comment
Share on other sites

As I read more I have another question about this. Does this same current limitation occur when using a read only share?

For example, if I sync the parent directory from machine1 to machine2 as read only (this is stricly for a backup purpose) can I still NOT share subfolders to a third machine?

original message

Sorry but you still can't share a sub folder, even if it is a RO share. Hopefully they will support this soon.

Link to comment
Share on other sites

  • 1 month later...

I'd really like this type of nested shares as well (Just like the picture that you guys have attached to this thread).

My scenario:

  1. A "local server" needs to be backed up to a mirrored (off-site) server. The top-level, entire file structure needs to be synced and backed up.
  2. [This is the nested part]: individual directories on the "local server" need to be synced with individual computers in the office. The nested shares will be shared to different computers than the mirrored "back-up" server.

Currently, this doesn't work with the way BTSync works. We'll have to find another solution for one of our two requirements.

I don't think using .SyncIgnore will help with the top-level back-up, since we really do want ALL the files synced to the back-up.

Looking forward to solutions.

Link to comment
Share on other sites

Looking forward to solutions.

The only viable solution at present, as mentioned previously, is to NOT sync the parent folder, but rather sync each sub folder separately. This will allow you to sync all these sub folders to one device, and then individual sub-folders selectively sync'd to other devices as required.

Link to comment
Share on other sites

It does!

I'd like to see proof of this as it's absolutely a dealbreaker for me.

When I'm trying to create a new sync-job for a folder within another folder, which is already synced, I get this: "This folder cannot be added to SyncApp as it is part of a folder that is already syncing."

I'm getting the same error. I already have directory /nas/sync/foo shared, and I cannot add directory /nas/sync/foo/bar as a separate shared directory.

What version of SyncApp are you using?

1.0.134 Linux x86-64 (I also tried 1.1.15 and still get the same error)

post-24928-0-73425100-1371867574_thumb.p

Link to comment
Share on other sites

I'd like to see proof of this as it's absolutely a dealbreaker for me.

Ha! The remainder of your post is the proof!! :P - you cannot add sub-folders to BitTorrent Sync separately if their parent folders have already been added!

This is why you are seeing a "This folder cannot be added to BitTorrent Sync as it is part of a folder that is already syncing" error when trying to add the folder "/nas/sync/foo/bar" to sync, if you've already previously added "/nas/sync/foo/"

Link to comment
Share on other sites

However, this is an artificial limitation because all the shares are managed by one instance of BTSync and it's (currently) unable to cope with a file/directory belonging to two different shares.

To do this you have to have two instances of BTSync running, one for the overall share and one for all the "little" shares. On Windows this has to be done by putting the two copies of BTSync into separate sessions; say by using "Fast user switching".

BUT, beware of using this technique with overlapping writeable shares; the *.!sync files from multiple BTSync daemons will collide and could cause files to be lost or corrupted.

This is one of the reasons I think *!sync files are a bad idea. The worst one though is fragmentation, the *!sync files are usually very very fragmented (because they're created from random pieces) and should be copied to the final location to reduce or even remove this fragmentation.

Link to comment
Share on other sites

It does!

I'm curious as to how you managed to get it working.

Using 1.1.15 right now, I can't seem to setup nested shares relying on the .SyncIgnore trick, with a directory hierarchy like this:

/Shared/.IgnoreMe/.IgnoreMeToo/ToShare/

Created a first share "Shared", which has a .SyncIgnore defined to ignore ".Ignore*" patterns (and it works, as evidenced by .Ignore* folders not being synced across machines). Still, creating a second share for "ToShare" results in the infamous error message about nested shared folders blah blah.

I'm surprised there's been little if any improvement ever since the issue was raised - it's indeed a dealbreaker.

Link to comment
Share on other sites

  • 1 month later...

Hmm so the problem still consist (1.1.48)

I find the .ignore* thing a bit ugly. I would like to maintain the flexibility i have by sharing all my important data in one share, so sharing all the sub folders separat is not an option.

A solution i though of would be to create a copy of the subfolder you want to sync, outside the main share. One can keep the copy in sync with the "original" using something like rsync+cron. Then you can create a secret for that "copy" of the subfolder and share it to whatever it is that you want to share just the subfolder to.

So i have my main share "/filer" huge, contains all the files i need synced. All my PCs can handle it, but my phone does not, i still want to sync the subfolder "/filer/musikk" to my phone. I pick a PC i see fit (should be one that is online 24/7) and create a folder besides "/filer" called "/phone" Then i use rsync+cron to make "/filer/musikk" sync one way to "/phone/musikk"

I create a secret for "/phone" and share to my phone, and there it is. The PC running the intern folder synchronization is so to say a bridge, from one btsync share to another.

I could share the secret to my other PC's to increase speed/availability (of course putting the "/phone" share besides "/filer", not inside "/filer"), however the syncing/updating from "/filer/musikk" to "/phone/musikk" only works as long as the pc running the "bridge" (rsync+cron script in my case) is online.

And no matter on which pc "/filer/musikk" changes, the changes will translate to "/phone/musikk". Not directly, but via the PC running the "bridge".

This is just a theory, i don't have time to test this right now.

also i'm not sure how this would work if you wanna do two way sync form the node that only has the sub-folder share, but i guess it is possible, just taking some precaution with who and what has write access.

Link to comment
Share on other sites

  • 2 weeks later...

This is devastating. I was so keen on BTSync; have set up multiple machines with 25GB shared. It's fast to update on file changes, no reliance on slow or expensive cloud servers, multiple redundancy. All good.

But I need to allow access to (sometimes-overlapping) sub-trees to different users, for example everything to some, sales-info-only to others, sales-and-purchasing to others, etc. etc.

.SyncIgnore doesn't work (the infamous error message and won't work with differently overlapping sub-trees).

There is also the problem of separate folder syncs with Incloudibly (cloud BTSync server): they only allow one key for your storage bin. If we can't sync sub-trees then we need multiple storage bins and that is expensive and cumbersome.

Is there going to be an elegant fix to this?

Can anyone suggest an alternative to BTSync? Unison perhaps?

Aside from this - thanks to everyone that has contributed to making it work so well already. It has great potential.

Link to comment
Share on other sites

  • 3 weeks later...

I, too, would really like this feature. Even the hack---allowing me to sync subfolders which are explicitly .SyncIgnore'd in a larger synced folder---would be a good first step for those of us who are desperate. That's simply a matter of updating the logic that verifies that a folder is not a subfolder of a synced folder: just add an additional check to see if the folder is .SyncIgnore'd and allow it if so. I bet it wouldn't be more than two lines of code.

 

For what it's worth, I would be happy to hack on C or Perl code if BTSync was written in either, and open-source. But alas, I simply must wait for the developers to figure it out on their own. Obviously they do great work, but this is an itch I'd love to scratch, and can't. :-(

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 weeks later...
  • 4 weeks later...
  • 2 weeks later...
  • 2 weeks later...

I feel nested shares would be brilliant for when you are using some hosts mainly for bandwith. With BTsync I can make a sync folder where everything goes to my fileservers. That is nice, but when you want to keep sub folders for 20 friends, making rules and adding each to three computers gets rather tedious.

If I have a folder structure like this:

BTSync -> private, friend1, friend2, friend3, friend4, family

Then I'd like everything within BTSync to go from my laptop to fileserver1 and fileserver2. This ensures that anyone downloading their folder, or updating it, will always get as much bandwith as possible. Ofcourse I could manually add each folder to sync, but that would require adding far more folders, and a lot more complexity. Especially now that there hopefully will be ways to use the encrypted secrets. Then having one folder that seeds everything seems like the best option, rather than having several folders to add. If you just have one it is a simple configure and forget setup, if you need to add every single folder to all the devices you need to do much more.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.