nils

This currently only works with the mobile clients and the API. If you just connect two desktops, everything will be synchronised.

I lost my shared folders completely after a few times of opening and closing. The camera backup was also affected, which showed an empty secret, although it was enabled before. I uninstalled it and downloaded it again, reentered all the secrets and it seems to work for the time being. Hope this was just an update glitch.

Please take a look at this thread. BTsync saves configurations in .sync, wherever you have placed the binary, otherwise btsync --conf <path-here> does the trick. Not quite sure why this is bad .... Please be aware, that BTsync is still BETA. As long as it is, it would be wise to not to use it in a production environment unless you are fully aware of it and have some sort of other robust backup system in place. In my case, I sync folders, which I track through git already, but for convenience I share some subfolders with others. All my shares are synced to FreeBSD servers, which have ZFS snapshots, so in case BTsync is buggy, I can just roll back. To avoid some of the problems others have with multiple RW shares, I have usually one master RW and multiple RO nodes. HTH

If you disable Automatic sync (per share) on the mobile clients, you will see all the available files in this share. Unless you select them, they will not be synced to your device. On the iOS client, documents with a green tick are on the device, whereas document icons without it are not downloaded.

No, your clients only transfer and exchange the data corresponding to the secrets that you have supplied to them.

The sticky post with the title "Latest x.x.x. build" has all the release notes for mobile and desktop/server clients.

The current implementation of the Photo Backup function on the iOS BTsync client does exactly what the OP's scenario describes: 1. Enable Photo Backup on phone 2. Copy/send email with secret to desktop/server BTsync and this synchronises all photos. 3. Delete photos on the iOS device 4. Does not synchronise to the desktop/server version.

Not yet, because the mobile clients do not have user preferences regarding tracker, relay and predefined hosts, to name the few that would be necessary to be independent of any Bittorrent infrastructure. If you would use desktop and server versions only, you can change the necessary settings.

There is no way to get text keys from the iOS app - apart from the photo backup secret.

There is no explicit switch/option to turn a node into a tracker. Maybe add it to the wish list, to get it on the developers' radar again.

a) yes. yes. disable DHT, relay, and tracker and any data sent will only go through your nodes. c) BTsync does not synchronise files that are locked by any other process. In some cases this might happen, as soon as you open a Document, or just when it saves a document, but it depends on the editor of your choice. No GUI to resolve conflicts is available at the moment. d) no option available that would separate LAN from WAN speed limits e) if you are overly protective of your data, using VPN increases the difficulty for any attacker to access it. BTsync does not bind to any specific adapter currently, therefore you would need to address this issue e.g. with a full tunnel.

Two arrows is as you said a direct connection whereas a cloud icon means, that you are connected to this peer through the relay server operated by Bittorrent. The use of the relay server can be deactivated per share. You could also try to enter the IP/hostname and port of the other nodes, which would enforce a direct connection, if no firewalls are in the way. This method does however need to have static IPs or domain names, or dynamic hostnames.

Hi brusker, If you have created entirely new keys, than this should not happen. How did you see/verify that the one person still has access to the files? Edit: Maybe take a closer look at the BTsync activity log: create new files and see with which nodes your btsync is synchronising. Sometimes a restart of BTsync does wonders, if you do things like changing keys.

Mobile clients already support this behaviour, selective sync - only through the API - is on the way to make it accessible to desktop/server clients as well.

this is why BTsync is still in beta testing, fixing issues is the MO for the time being. Take a look through the normal sync.log and/or enable debug mode to get more info into the sync.log. Maybe you will see the file names that were not indexed.

As long as BTsync is in beta, I would suggest to check the bittorrent website and forum for updates.

BTsync is still in beta and the API T&C's are not entirely clear for developers, therefore some developers have been put off on further API development. And as it is still beta, things might change in the future. The fact that there is no BTsync roadmap accessible to the public does not make it easier for people to ascertain where it is going. Despite all this, a multitude of programs are available interfacing the API or integrating it into e.g. Drupal. Have a look at the API forums if you are interested.

he would, if he would be lucky enough to hit a secret that is actually in use. The odds are not in favour for him. Some people even use longer secrets, several 100 characters long, further decreasing the chance of finding a secret.

Use the ubuntu/debian packages, which come with init scripts and options on which user is running the btsync service. in your config:

Have you started going through this? If you need further intro, the desktop guide is on the same page further down.

This is a known bug/limitation of the mobile BTsync clients. Deletion on the mobile client is only locally and does not propagate to the other nodes, just tested this with a RW secret on iOS 1.2.36. Edit: Sorry, OP was talking about something else. I have the same issue for an RO folder on iOS as well, where files are still shown although no longer available on any other node for that secret.

BTsync does not currently handle any kind of file name conversion for the different available file systems or case sensitive/insensitive filesystems. I am not sure if the developers will implement this in a future version, but for the time being the best practice would be to refrain from problematic filenames if one uses multiple platforms for syncing.

Hi mannixes, It appears that BTsync does not run on Mac OS X 10.5.8, because a linked library is not present. Maybe put a request for this in the wishlist thread, if you would like to see it supported in the future.

Yes, as BTsync just syncs data between YOUR devices, you need to have both of them switched on, if there are only two computers using the same secret.

Yes. Yes. yes/no. Your friend won't be able to decrypt your data, unless you give him the RW or RO secrets of the share. What I meant was: in case of a disaster i.e. your laptop caught fire and the server you have running gave up its ghost at the same time, you would NEED to have at least an RO secret at a third location, with which you then can set up a new client and your data would be synced back. http://www.bittorrent.com/sync/developers/api HTH