nils

Try this http://www.bittorrent.com/sync/get-started

It depends, if btsync discovers the VPS as a LAN client - which btsync determines with multicast messages, see the documentation on peer discovery http://www.bittorrent.com/sync/technology. If your openvpn is configured as a bridge and multicast messages, such as mdnsresponder etc come through and vice versa, then it should use the LAN IP. The sync.log should show the connecting IPs and I think they should be visible even without debugging.

Take a look at the advanced folder preferences at the RO node, you should find a checkbox named "Restore modified files to original version". (I assume you are using 1.2.71)

One thing that could impact your data transfer is the relay server, which is enabled by default for every shared folder. Some also had improved transfer speed when enabling TCP for LAN only syncs, see the advanced settings.

All I tested was if files were locked if iTunes was not running, I did not sync anything. You might have to take a look at "Enable debug logging" from the BTsync menu. The sync.log should be in ~/Library/Application Support/Bittorrent Sync/

The files described by the OP are not locked if iTunes is closed, I checked with lsof in the terminal whilst running it and once when closed (iTunes 11.1.3, OS X 10.9).

I can confirm that this line appeared in my RO nodes' sync.log with a file that was excluded on the RW master, but synced to the RO nodes before. I put the file extension into my SyncIgnore file at a later state, therefore it was synced, and the RO nodes were trying to sync it because I selected "Restore modified files to original version". I had to delete the conflicting file on every RO node before it disappeared.

It means, that the connection to this node uses the relay server set up by the BTsync guys. Sometimes a direct connection is not possible between nodes and if you have checked "Use relay server when required" in one of the folder's settings, that share will use the relay if necessary.

iOS client: Add the same features of the desktop app to the mobile appSettings per folder e.g. use TCP at LAN, Restore modified files to original version, QR code to let others connect mobile-to-mobileDevice namesUpload tabEnable deletion of files from the iOS surface on RW shares, not just "Cancel" or "Delete" from the deviceDekstop/webUI version: Allow creation of ENC keys with a user defined secret (through API?)Show a list of not yet synced files and therefore simplifying the identification of locked files from the UI without going into debugging, Could be integrated into the Transfers with an option "Show locked files" in the advanced settings.Thanks again for the updates Edit: I reckon this has popped up a few times as well, as I have just seen another topic reply by GreatMarko regarding what Sync thinks are identical files: An implementation of SHA1/x MD5 file checksums and others would greatly help you identify e.g.: - Do a comparison of checksums, maybe even database of checksum+file location in share? - This would prevent problems with timestamps etc Already implemented according to HaroldFeit Edit 2: Add a --debug option or -v -vv -vvv switches to the binary to turn on debugging for a session, maybe even a switch for demonising, as well as including these options in the config file.

Got it working with a sample config generated with Python from another thread . My minimal config : { "storage_path" : "/Users/username/Library/Application Support/BitTorrent Sync", "use_gui" : true, "webui" : { "listen" : "127.0.0.1:8888", "api_key" : "XXX" }

I have tried the same on 10.9, but was unsuccessful. Can one of you post a working config?

You can now browse through the files of a share with the get_files method and download them with the set_files_pref method. These are currently only available through the API. The methods are described in the documentation http://www.bittorrent.com/sync/developers/api

When you say "almost as much time", does it really download anything? If it does not download anything, BTsync could just take long for the indexing. You could check in the GUI if there is any download activity.

It depends on how you "installed" btsync. If it is a service i.e. you start it through /etc/init.d, then maybe take a look at the script and change user and umask respectively. If not, then you could switch to the user www-data:pi with su and then change the the umask with the umask command.

Deduction from generating keys with BTsync itself and also some comments seen on the forum. The GUI does not create keys with ENC support, therefore the A and B secrets. The API is the only way to create shares with ENC capability for the time being. From a business point of view it also makes sense, because this could be an enterprise feature, as API keys are needed to activate it.

I have a VM Superhub in modem mode running and a TP-Link N750 router with openwrt and everything seems fine. I have the 120/10 Mbit package and never had problems. I have to admit, that most syncing is going out only, as I sync my shared folders offsite.

If you look closely, the secret's first default character changed from Axxxxx (RW) and Bxxxx (RO) to Dxxxx (RW), Exxxx (RO) and Fxxxx (ENC), which means they are generated with a new function internally. In short, you can only enable encryption with new secrets. I also think this is a step backwards in making it impossible to create your own ENC nodes with a user supplied secret.

it should read: Advanced features available through API: new secrets with support of read-only encrypted peerssynchronize selected files only

+1 for some sort of documentation for the API and advanced settings.

BTsync does not have such an option ATM. The user and group are the same as the one running the btsync process, you could however change the umask temporarily, see http://www.eupcs.org/wiki/UMask. I have seen settings on user and umask in the package that tuxpoldo put together for debia/ubuntu.

BTsync does not allow editing in the "cloud" i.e. User 2 editing documents on User 1's computer like you described it. For this use case I would recommend a network share or something similar that would expose your data to someone else, maybe look into SFTP/FUSE, NFS, Samba, AFP and similar things.

Indexing is known to take quite a while for a large number of files. You can start the btsync client from the command line with a --config parameter and then point it to a config file, if you would like to configure it that way. This way you can either take part of the control away from the webui, or disable it completely by including shares and secrets in this file. The btsync binary can produce a standardised config file with --dump-sample-config. btsync --help shows you the currently implemented command line options as usual in Linux/Unix.

The files are in the .sync folder, however, they are not in a readable or editable format.

I am not sure you get the nature of BTsync at its current state: a synchronisation tool (with minimalist backup .SyncArchive implementation). BTsync is not here to obliterate a good working backup solution, which would be able to prevent data loss as described in your case. The first case of renaming files, which are added again, could maybe prevented by BTsync, if an md5/sha1 would be saved for each file, but that might blow up the database for large shares as well. In short, it is not an easy solution and should go into a Known issue part of the documentation for the time being. FYI: dropbox known issues https://www.dropbox.com/help/145/en

BT sync's transfer speed might have something to do with the implementation. It is closed source and therefore hard to tell how it can be changed/improved, unless the debs make configuration options available. Other causes for slow speed could be on the ISP side, blocking and/or slowing down of P2P traffic.