GreatMarko

In which case, instead of syncing the entire parent folder, and then also setting up separate syncs for sub folders - you would need to create individual syncs on the relevant sub folders - don't also sync the parent folder - as this will cause problems! OR.... if you really want to sync both the parent folder and sub folders separately, you would need to use .SyncIgnore on the parent folder to EXCLUDE the sub folders you're syncing separately from that parent sync:

You are syncing "c:\folder1" on machine 1 with "d:\share1" on Machine 2. "d:\share1" has a sub folder, "sub1" - therefore this will replicate back and a "sub1" folder will be created and then synced on machine 1 at c:\folder1\sub1

Your best option, instead of syncing your whole "PROJECTS" directory, would be to create a "Shared" sub-folder and only share that - that way, you can simply copy only those projects you wish to share with colleagues into your "shared" sub folder

Well, my attachments do appear to be working (tested on 3 different browsers on 2 different computers!) Anyway, I can see your scenario from your drop-box link, and it would fall under the "parallel sync" scenario above. Assuming that all your indicated syncs are R/W, not just read-only, your image also doesn't take into account that your "sub1" share on Machine 2 would also replicate back to a "folder1/sub1" on Machine 1!! ....so, yes, this will cause you problems!

Unfortunately, your image attachment isn't working, so I'm not sure what your "scenario" is? However, going off your topic title of "nested shares", I have previously extensively tested a number of scenarios in this regard, as illustrated in the attached images. It should be noted that both of these sync setups can cause problems and should be avoided! Scenario 1 - "cross" sync Parent Folder A on Device A is set to sync to Sub Folder B (of parent folder A) on Device B ...and at the same time... Sub folder B on Device A is set to sync to parent folder A on Device B Scenario 2 - "parallel" sync Parent Folder A on Device A is set to sync to Parent Folder A on Device B ....and at the same time Sub folder B on Device A is set to sync to Sub folder B on Device B ...as I say, both of these setups can cause you problems, and should be avoided (unless you make use of .SyncIgnore to "hide" folders from SyncApp). The SyncApp team are aware of these scenarios, however, it would be quite unlikely for regular users to be setting up syncs like these (as there's no reason to do so anyway!) Now, I don't know if this covers your particular "nested share" scenario, but if not, perhaps you could attach your image again?

So why not just have SyncApp sync .SyncIgnore files, so that when you make changes to a folder's .SyncIgnore file, those changes propagate to the corresponding sync'd folders on other devices? ...would that not solve the problem/avoid the need to manually make changes to the .SyncIgnore file on each device?

I'm not sure I quite follow? What's wrong with having the .SyncIgnore file on BOTH devices being identical and ignoring, in your case, "*~", "*.bak", "*.o" "*.iso", and "*.sh"?? ...that way, none of those files will sync between devices.... which is what you want, right?

Yes, just map the network location to a logical drive, and you should be good to go!

No, its purpose isn't intended to delete files - just to ignore them when it comes to syncing! I'm looking into trying to replicate this issue at the moment.... but my initial thoughts are that it may be due to the fact that the .SyncIgnore file itself doesn't sync between devices! Therefore, if you've got two folders in sync, and you edit the .SyncIgnore file in one of them to start ignoring certain files, those files are then excluded from that folder's index - meaning that potentially other sync'd devices then no longer see these files, and so mistakenly assume they've been physically deleted from the original device... ...as I say, that's my initial assumption, but I'm going to have a go now at trying to replicate this, and I'll let you know what I find! UPDATE: I can confirm that this does appear to be a bug, as I can replicate this issue. As I suspected, it appears to be due to the fact that the .SyncIgnore file itself doesn't sync between devices. WORKAROUND: Until the SyncApp team are able to address/fix this issue, the work-around to ignore specific files from syncing is as follows: 1. Close SyncApp on all your devices where the folder in question syncs 2. Edit the .SyncIgnore file within the folder to add your custom ignore filter(s) 3. IMPORTANT: Do this for ALL the .SyncIgnore files for the corresponding folders on all your other devices where your folder syncs (i.e. the .SyncIgnore file for that folder on all your devices should be identical) 4. Start SyncApp again Your folders should then correctly sync, ignoring (and not removing!) the files you've specified!

This is already discussed in the following thread.

As has been indicated in another thread there are plans for an API for SyncApp at some point.

With SyncApp 1.0.90 (and later) you CAN filter which files are synced/ignored - please see the hidden ".SyncIgnore" file in each folder you're syncing for more information

Yeah, hopefully in time SyncApp will be able to "auto update" itself without any user intervention, so that your devices will all be running the same, most up-to-date build!

I would like to echo this request - in my experience, if a device is running a different version of SyncApp to other devices, it will no longer show up in the devices list/sync at all - it would be very useful for devices running a different version of SyncApp to still show up in the "Devices" tab, but indicate in some way that SyncApp needs updating on those devices

Kos, Is there a Changelog anywhere so we can see the differences between releases? i.e. 1.0.90, 1.0.92, and the latest 1.0.95. This might help users when reporting bugs as they'll be able to first check to see what bugs have been fixed in the latest build!

Is SyncApp doing anything else at the time? i.e. if it's currently indexing a very large folder, I've found that this can sometime delay the syncing of other folders. Also, with build 1.0.92, SyncApp now has the ability to "ignore" certain files (by default ".DS_Store", "desktop.ini" and "Thumbs.db") - if you add any of these to your folder (or any other files you've chosen to exclude from the sync), they won't be indexed/synced I did occasionally with the previous build (1.0.75) find there were times when folder changes were not detected straight away, and I ended up restarting SyncApp, which then detected the changes straight away - this was very intermittent for me with 1.0.75, but it maybe that that issue is still present in 1.0.92? As I say, check to see if SyncApp is currently indexing other folders and potentially therefore delaying other folder's sync, and make sure the files your adding to the folder in question don't match the list of ignored files (see the contents of the folder's hidden ".SyncIgnore" file)

Remember as well that if you're only ever syncing devices that reside on the same LAN, you can always disable relay/tracker options if you're concerned about security!

SyncApp is designed to share complete folders, rather than individual files. The simple solution is to create a folder dedicated for sharing with others, and only drop the files you wish to share into that folder. There is an alternative (although this would seem to be a very long winded way of achieving what you want, and I wouldn't really recommend it) which is to make use of the ".SyncIgnore" hidden file present in your sync'd folders (as of SyncApp 1.0.90). This ".SyncIgnore" file allows you to list all the files within the folder that should be ignored by SyncApp. You could, therefore, technically list all the files in your folder apart from the few you wish to be "shared" (sync'd) ...but this could be a laborious process - you'd be far better just creating a dedicated folder for sharing files with others, and only drop in there the files you wish to share!

I actually think the email address at the top of this thread may be incorrect - try sync@bittorrent.com instead of syncapp@bittorrent.com

Yes, a number of users (myself included!) have requested the ability for SyncApp to start truly minimized to just the system tray only (and not also be present in the taskbar)... so the SyncApp team are aware of this request! Hopefully it might come with the new build next week! EDIT: BitTorrent Sync (previously known as "SyncApp") now starts correctly "minimized" to the System Tray

@rdebath - I really don't have a clue what you're going on about in your last two posts!!?? But if you read the previous comments in this thread from both mysel and Kos, you will see that the next release of SyncApp will not enforce a specific Secret length (as it does at present), and will also permit symbols as well as alpha-numeric characters. As I outlined previously, a 6 character long secret would allow for around 56,800,235,584 unique "secrets" (nearly 57 BILLION!) (and that only assumes a secret made up of just A-Z, a-z, and 0-9 characters. Add symbols into that mix and increase the secret length further, and the possible unique combinations are just too big to realisticlly express here! So, given the upcoming flexibility of secret lengths, how secure a user's SyncApp is will to some extent be up to the user! Longer secrets will make it more secure than shorter secrets... so why not just create and use secrets with a length of say 2048 characters(!) If users and/or cryptologists "would disagree" as to how likely it would be for someone (or a computer) to "guess" someone else's secret given these forthcoming improvements to secrets - if they're really THAT worried about it, they can always choose not to use SyncApp!

So what do these buttons do then, Kos? I'm guessing that maybe "R/W key" generates a secret to allow multi way syncing (i.e. "read/write"), where as "R/O key" generates a secret to only allow one-way syncing (i.e. "read only")?

Yes, but the point is NO system/app can guarentee 100% "unbreakable/uncrackable" passwords/codes/secrets - however you want to term it! As Kos has made quite clear, SyncApp will allow "you to use your own key of any length. We are sure that key of 21 truly random bytes are enough, but you are free to use any key you want." So there will be nothing stopping you having a secret with a length of 256 characters, 512 characters, 1024 characters, 2048 characters... or more!! Let's take a very simplified example - let's say each character of a secret can be one of 62 possible chracters (a-z, A-Z, or 0-9) (in reality there would be more than 62, as symbols, etc are soon also to be allowed) - but let's just stick with each character of a secret being one of 62 possible characters. Therefore, A 1 character long secret would allow for 62 unique "secrets" A 2 character long secret would allow for 3,844 unique "secrets" A 3 character long secret would allow for 238,328 unique "secrets" A 4 character long secret would allow for 14,776,336 unique "secrets" A 5 character long secret would allow for 916,132,832 unique "secrets" A 6 character long secret would allow for 56,800,235,584 unique "secrets" ...and so forth! So hopefully you can see that as the length of the secret increases by just 1 character, the chances of "guessing"/generating/inputting the same secret as someone else decrease exponentially! - and right now SyncApp is generating secrets of 21 character length (the number of unique "secrets" this offers is a number too large for me to express here!) Even so, by removing the current 21 character secret length limit (which Kos has confirmed is happening) AND allowing symbols, etc in secrets (which Kos has also confirmed is happening) SyncApp is going to be even more secure! But at the end of the day, If you're then still worried about someone potentially "guessing" your SyncApp secret, or SyncApp inadvertantly generating the same secret as one of your folders for another user... the answer is simple... don't use SyncApp! No-ones forcing you too!!

Please see my previous comments in this thread - you can join the "waiting list" to become a tester by following the information/link at: http://labs.bittorrent.com/experiments/sync.html However, be aware that I understand there to be a wait time of at LEAST 6 weeks, if not longer. Also, if - and I do stress **IF** - the SyncApp team are generous enough to offer any additional invites directly through the forum (in a similar way to what Kos did in this very thread nearly 6 weeks ago), it's likely that this would only happen just prior to a release of a new version for testing (as it did back in Feb). The SyncApp team have already said that the next update to SyncApp won't be before April - therefore, I wouldn't be expecting any more invites until then! Also, please note that unlike other software, such as AeroFS, where existing users can simply "invite" other users to use the software, this is not the case with SyncApp. Existing SyncApp users are unable to "invite" you to join SyncApp. Asking for invites here in the forums, or PM'ing existing users with such requests won't work! So my best advice to Wync, piersh, and anyone else desperate to try SyncApp would be: 1) Make sure you sign up at http://labs.bittorrent.com/experiments/sync.html 2) Regularly check back to this forum to see if the SyncApp team do release any additional invites here.

Yeah, there have been a few requests now for the sys tray icon to indicate that SyncApp is "doing stuff" i.e. animate when syncing / show whether syncing is paused, etc - so I'd just like to echo your request!