delegatevoid

It's a bullshit move. We (the entire community here) have been testing and providing feedback for btsync since the very beginning. I'm sure there are many like myself who have set up many sync folders, moving from other services such as Dropbox, GDrive, etc... to BTSync because of the promises made by the Bittorrent team. And now they want to limit us to 10 folders (which is a purely artificial limitation) unless we cough up money for every device in our sync setup? This doesn't just affect business users, it affects all users. Of course they have every right to make money (and they should), but business support should have been something like: 24/7 technical support active directory / ldap integration bla bla bla Here's what we'll do. Backup all binaries of the 1.4 versions for every platform and keep using those. Since it is supposed to be purely p2p they should continue to work, if they don't we'll know there's something in the middle and the product as a whole should not be trusted. When they come up with more acceptable terms for the 2.0 we can reconsider.

This is rather important isn't it :-) Otherwise no commercial product would ever be able to support BTSync, so they'd only be able to support Dropbox, GDrive, OneDrive, etc, etc....

The problem is I'm letting JSon.net do the parsing automatically, don't feel like doing it manually just because the BTSync team fix it. It still feels like this whole thing is someone's pet project :-)

Epic

If you look at the preferences in the latest version of BTSync, the values of some settings are being prefixed with "*", even though, when you set them, they are pure integers. I've no idea what the meaning of this "*" is, but what I do know is that it breaks the API. If you look at the JSON returned by the API: You'll see it returns "*" as part of some values which means they can no longer be parsed as integers which in turn breaks the clients.

@marck321 You are correct, thank you for pointing it out. Apparently the response to this API request has changed, I will have to check what is going on. @lg0 The open source repository for this projects can be found on BitBucket (I am not a fan of GIT) https://bitbucket.org/timothyp/arendee-btsynclib Feel free to post bug/feature requests there. As for 4.0 support, I'm afraid not, since the library relies heavily on async/await. That being said, you could backport it to use .NET 4.0 and the Async CTP for .NET 4.0, however I wouldn't suggest it. Today Windows XP is the only version of Windows not supported by .NET 4.5 and nobody should be running that anymore anyway. If you do want to backport it, perhaps you can fork the repository in GitHub, create a new branch for .net 4.0 and if it's good I'll pull it back into the main repo And of course I'd be more than willing to help out if need be. @mark321 I looked into it some more, it's actually a bug in the new version of BTSync The values marked with a * should actually just be integer values, and since the latest version they are not. Will post this as a bug Update: I've posted it here: http://forum.bittorrent.com/topic/31616-bug-preference-values-in-btsync-14x-contain/

You are correct, should be public Program() { ... } I wrote that on my Surface using notepad, as I just received it and hadn't installed Visual Studio yet. A typo, my bad, sorry

In this particular case, if your application doesn't do anything else at the same time, you can get away with using .Wait When you build bigger applications or desktop applications .Wait() will not be suitable. As for the BTSyncClient instance, there's no need to do that before the try. In fact, if you have a try/catch in a method you should always try and make it so that the try is the very first thing in the method.

Hi, You are correct to say that the methods in the library are all asynchronous. By default this means fire and forget. You start a Task which gets executed somewhere else and your applications imply continues to execute whatever line of code follows. I'm sure you are using a console application so here's what's happening Your application starts at the entry point public static void Main() It executes the code in that method, starting with whatever logic you use to start BTSync It then creates the folder (be careful where you create it, your application may not have access to that location) Then you start a new task by calling client.AddFolder but that method is asynchronous, so it (to put it simply) gets executed somewhere else and your main thread does not wait for it, instead it continues to execute the next line in your main method. If there is nothing there, your application will close and the task along with it.While your answer, posted above, would work, it is not the correct way of using the code. Instead you should use the async/await pattern in C# (http://msdn.microsoft.com/en-us/library/hh191443.aspx) Consider the following (a little over simplified example): using Arendee.BTSyncLib;using System;using System.IO;using System.Threading;using System.Threading.Tasks;namespace BTSyncExample{ class Program { private bool exitApplication; private string server; private string username; private string password; private string deviceName; private int port; static void Main(string[] args) { new Program(); } new Program() { //Replace the values here to fit your setup Run("localhost", 8888, "spongebob", "squarepants", "HelloBTSync"); while (!exitApplication) { Thread.Sleep(500); } } public async void Run(string server, int port, string username = "", string password = "", string deviceName = "YourAppName") { this.server = server; this.port = port; this.username = username; this.password = password; this.deviceName = deviceName; StartBTSync(); await AddBTSyncFolder("c:\\test", "yoursecrethere"); Console.Write("Press any key to continue..."); Console.ReadKey(); exitApplication = true; } private async Task AddBTSyncFolder(string path, string secret) { try { if (!Directory.Exists(path)) { Console.WriteLine("Creating directory: '{0}'", path); Directory.CreateDirectory(path); } Console.WriteLine("Adding the folder to BTSync"); var client = new BTSyncClient(server, port, username, password, deviceName); await client.AddFolder(path, secret); } catch (Exception ex) { Console.ForegroundColor = ConsoleColor.Red; Console.WriteLine("Add folder failed: {0}", ex.Message); Console.ForegroundColor = ConsoleColor.White; } } private void StartBTSync() { //Do whatever you need to to start btsync } }}Start by looking at the AddBTSyncFolder method. It's signature includes the async keyword and returns a Task. Simply put, a Task is something that will get executed somewhere else and you can wait for it to complete. After creating the folder it creates an instance of BTSyncClient and calls AddFolder. await client.AddFolder(path, secret);Note the await keyword. This means the method execution will stop at this line, the AddFolder task will be started, and when it has been completed, method execution will resume as if nothing happened. (Note that the AddBTSyncFolder function is not a clean function, it does two things, creating a folder and adding it to BTSync, normally a function should do one thing and one thing only, but for the purpose of this example it should be fine) The Run method is also defined as async but it does not return a Task. An async method that does not return a task is truly fire and forget. It is started and there is no way to wait for it. It has to be like this because, otherwise any method calling Run would have to be asynchronous as well. The main entry point for your application and the constructor of the Program class cannot be asynchronous, so Run does not return a Task. (For more info on this check out articles referring to async/await being contagious). So finally there is the constructor of the Program class which calls Run. It will start executing the code in Run but it will not wait and if you do nothing after that line, your application will, once again, simply exit. So I've included a while loop which will put the main thread to sleep until exitApplication is set to true. It may seem a little counter-intuitive, but that's because async/await does not really lend itself for use in a console application. That doesn't mean it shouldn't be used in console applications, it just means that there's a little extra work to be done to make it behave properly. A desktop application for example, does not exit until all windows have been closed so there is no need for a wait loop. The async/await pattern is particularly useful in desktop application as a way to perform long running tasks without freezing the UI thread. (Remember the infamous 'Application xxx is not responding') Once you get the hang of async/await you'll wonder how you ever got things done without it, so if you can, invest some time in learning more about it, you will not regret it. I hope this helps, and if you have any more questions, just ask.

It's been a while

Pssssst... it's a dead link

Hi, I'm not aware of C++ implementations except for the first result on google: https://github.com/boxdot/btsync-cpp Perhaps that one can get you started.

If it works it works

Hey, Any updated ideas?

Any suggestions as to where we can put this up?