tuxpoldo

I fully agree on this. And this is exactly reason I wrote: "I'm not sure, that it's now the time to provide a central library that has to be updated, maintained, distributed in various distributions, etc... This would only slow down the application development..." and "...I am sure, that you would find lots of things in my code why you would never use it in your application." Currently everybody of us has different requirements to such a library. Before starting the implementation of a general approach, we should understand all these requirements and the only way to do it, is to develop the first real life application in order to understand and collect our requirements. Currently I think that after looking at all those libraries I can identify three main requirement categories: Communication: thin API wrapper that communicates with a known running instance of BitTorrent Sync and provides all available API methods Local process management: Facility that manages a well defined local environment of BitTorrent Sync including process start, stop, suspend, resume and protection against security issues, environmental issues (directory availability, configuration file, access rights to needed files and paths) Deployment: Facility that manages the retrieval and installation of BitTorrent Sync in order to provide the prerequisites for the former two facilities to work...e.g.: In my application, I need the first two of these. What do you think about this?

Believe me! This makes it really hard to handle the strings correctly. Look at this ugly code and this much more ugly ways to handle it....

OK. Here a quick and dirty collection on my thoughts... The first approach was published here and it is not in the list you wrote: https://github.com/BrandonIngalls/BTSyncAPI - it was definitively not complete (since it covered only a few methods) but it was the starting point for my implementation. I only modified it in order to work with the request library, support the strange charset conversion stuff, support both exceptions and return codes, etc. It is only a client library. Nothing more. And since it is really a very thin layer that may change often, I'm not sure, that it's now the time to provide a central library that has to be updated, maintained, distributed in various distributions, etc... This would only slow down the application development... Please do not consider my thoughts as a quality judgement about your software! I am only telling, why I would not use it in my solution and this may perhaps be some criteria to take in consideration when creating a general available wrapper. I am sure, that you would find lots of things in my code why you would never use it in your application. And now a fast look at the other libraries: Jack Minardi: https://github.com/jminardi/python-btsync I would not use it in my application since: It is still not complete. Only 5 methodsWay to much imports: 7 libraries only to make a few HTTP requests? We should KIS (keep it simple...)Implements authentication by fiddling manually with headers...Scope unclean: contains a generator for a config file... A client library does not have to deal with managing the server process.... BTW: the checked in Source on GitHub contains a hardcoded API key. Not exactly what the terms and conditions require...def start(self): - this function is not only out of the scope of the API, it is also not really deterministic, since it does not handle all problems and implications of managing the process.Tiago: https://github.com/tiagomacarios/pybtsync I would not use it in my application since: Way to much imports: 11 libraries only to make a few HTTP requests? We should KIS (keep it simple...)Out of scope: def write_conf_file(...): Hey! It is a client API!!! It is not a server process manager!Out of scope: def download_btsync(self, btsync_dir): Wow! Not only it tries to manage a local btsync process, it wants also to download the executable from BitTorrent Inc!It mixes together too much stuff: Getting BitTorrent Sync (but only on Windows and Linux!), Creating a config file (but without really supporting any possible feature - further more this creates an additional version dependency...), some approach of process management (def start_process(...)) but without providing all functionality needed to really manage a local btsync process....Kevin J. Qiu: https://github.com/kevinjqiu/btsync.py This is a really interesting project. The most important aspect is: It does not use the BitTorrent Sync API. It does instead rely on the Web Interface and uses the same access points used by the internal JS code of the Web UI. Because of this it cannot be treated like the other projects. What I like is: The project is very well structured (data model, classes, etc.) It does not try to do things that have no relation with the task like managing the process... It seems to be very compliant with a very canonical development process....This approach unfortunately has also some disadvantages: There is no guarantee that it will work, since it is using a very private, undocumented and internal interface that may be changed at any version... I'm quite sure, that in future the official API will permit to make lots of more things.... Performance issues?

OK: Try to connect from a browser of another machine Check which btsync process is running and how long Reboot your serverAnd no. You are definitively not the only one using jessie. Look: yeasoft-webhost2 /mnt/data/debian/logs # grep -c "/btsync/dists/jessie/main/source/Sources.gz" access.log2298 Today 2298 computers running jessie have done apt-get update.

Great!!!!

Hey! You are not the first one to ask the same question. But please tell me which part of this phrase is unclear: "Kann auf Grund fehlender API nicht implementiert werden" ("Cannot implement due to missing API"). As I understand it, it should mean: I cannot implement NOW this functionality since CURRENTLY the BitTorrent Sync API DOES NOT PROVIDE THE FUNCTIONALITY NEEDED to implement it. This was the intended meaning, when I wrote the phrase... BTW: the Issues are documented: See Issue #75 and Issue #76. This means: You cannot do anything.I cannot do anything.Only the developers from BitTorrent Sync can do anything: they can implement some more APIs that make it possible to implement this feature that is also existing in the Windows and Mac OSX GUI.And before you ask: No. I do not know, if and when they will implement it. I hope soon. Do you have any Idea how I can change the phrase in order to avoid some misunderstandings in the future? Feel free to post your suggestions both for German and English since I was responsible for both versions...

Have you done /usr/lib/btsync-common/btsync-core --help Are you really sure, that there is process still running based on another executable?... Please look also that the synbolic link is pointing at the correct executable: leo@debpoldo ~ $ ls -la /usr/lib/btsync/btsync-daemonlrwxrwxrwx 1 root root 28 Apr 7 22:01 /usr/lib/btsync/btsync-daemon -> ../btsync-common/btsync-coreleo@debpoldo ~ $ ls -la /usr/lib/btsync-common/btsync-corelrwxrwxrwx 1 root root 16 Apr 19 15:48 /usr/lib/btsync-common/btsync-core -> btsync-core-i686 ...and the only explanation for this behaviour may be: Your browser does something terribly wrong. Bad plugins? A caching proxy on the way to btsync? Something between the browser and btsync?There is an old version running somewhere on your machine...

Thank you! This is not a bug. The phrase "Cannot implement due to missing API" means that I cannot implement this functionality, since the BitTorrent Sync API currently does not provide any function that would return the needed data, but it is planned to implement this in the future. See Issue #75 and Issue #76. Mhhh. I think I will have to improve the way the input fields make sure, that only valid data can be entered. I know... it is strange and will work on it. Promise! See Issue #130 Cheers, Leo

Hi! I have no idea, what's the problem. The package in the repository is the same for all distributions. In any case I checked again, what is stored in the repository: leo@debpoldo ~/Development/btsync-deb $ reprepro list jessiejessie|main|i386: bind-shim 1.0-2jessie|main|i386: btsync 1.3.1-1jessie|main|i386: btsync-common 1.3.93-1jessie|main|i386: btsync-gui 0.8.2-1jessie|main|i386: btsync-gui-gtk 0.8.2-1jessie|main|i386: btsync-user 1.14.3-1jessie|main|amd64: bind-shim 1.0-2jessie|main|amd64: btsync 1.3.1-1jessie|main|amd64: btsync-common 1.3.93-1jessie|main|amd64: btsync-gui 0.8.2-1jessie|main|amd64: btsync-gui-gtk 0.8.2-1jessie|main|amd64: btsync-user 1.14.3-1jessie|main|armel: bind-shim 1.0-2jessie|main|armel: btsync 1.3.1-1jessie|main|armel: btsync-common 1.3.93-1jessie|main|armel: btsync-gui 0.8.2-1jessie|main|armel: btsync-gui-gtk 0.8.2-1jessie|main|armel: btsync-user 1.14.3-1jessie|main|armhf: bind-shim 1.0-2jessie|main|armhf: btsync 1.3.1-1jessie|main|armhf: btsync-common 1.3.93-1jessie|main|armhf: btsync-gui 0.8.2-1jessie|main|armhf: btsync-gui-gtk 0.8.2-1jessie|main|armhf: btsync-user 1.14.3-1jessie|main|powerpc: btsync 1.3.1-1jessie|main|powerpc: btsync-common 1.3.93-1jessie|main|powerpc: btsync-gui 0.8.2-1jessie|main|powerpc: btsync-gui-gtk 0.8.2-1jessie|main|powerpc: btsync-user 1.14.3-1jessie|main|source: bind-shim 1.0-2jessie|main|source: btsync 1.3.1-1jessie|main|source: btsync-common 1.3.93-1jessie|main|source: btsync-gui 0.8.2-1jessie|main|source: btsync-user 1.14.3-1In any case you can check, what you have installed and how it identifies itself: leo@debpoldo ~/Development/btsync-deb $ dpkg -l btsync-commonDesired=Unknown/Install/Remove/Purge/Hold| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)||/ Name Version Architecture Description+++-=========================-=================-=================-=======================================================ii btsync-common 1.3.93-1 i386 Private network P2P file synchronisation daemonleo@debpoldo ~/Development/btsync-deb $ /usr/lib/btsync-common/btsync-core --helpBitTorrent Sync 1.3.93Usage: btsync-core-i686 [--config <path>] [--nodaemon] [--generate-secret] [--dump-sample-config] [--help] [--get-ro-secret <secret>] [--log file]Options: --config - location and name of configuration file --nodaemon - do not use daemon mode --generate-secret - generate shared secret --get-ro-secret - get read only secret for existing master secret --dump-sample-config - dump sample config file --log file - force logging to file in non-daemon mode --help - print this message and exitSorry for the late answer. I was ill the whole last week...

Hi Jorah, sorry for the late answer. Unfortunately I was very ill and I could not read any mails... There is nothing wrong with your application. The phrase "Cannot implement due to missing api" means that I cannot implement this functionality, since the BitTorrent Sync API currently does not provide any function that would return the needed data, but it is planned to implement this in the future. See Issue #75 and Issue #76. Cheers Leo

I would say: try to go forward to 1.3.86 ;-) In any case you can see more, if you start btrsync-gui on a terminal. It outputs it's log messages directly to the terminal. You can also increase the log level from the command line and also make this change persistent. The log file is stored in ~/.btsync/btsync-gui.log

The idea is really intriguing... I think it's worth to be documented in a change request for one of the next versions of the Server Packages for Linux. See Issue #124

Ladies and Gentlemen, enjoy this new version featuring a security update and the possibility to bind BitTorrent Sync to a specific interface (see initial posting): btsync (1.3.1-1) unstable; urgency=low * Fixed access to several files in the storage path (Closes #122) * Updated spanish translation * Added support for post-installation triggers * Added support for bind-shim (Closes #94) -- Leo Moll <leo.moll@yeasoft.com> Tue, 08 Apr 2014 13:47:10 +0200

This issue is a known issue of 1.3.80 and is discussed in this thread. BTW: The discussion thread for btsync-user is this one.

There is very DIRTY way to revert: See here.

This problem has to be solved by the BitTorrent Sync developers, but in the meantime, here a quick and dirty way to "downgrade": Download the old version you want from the official download sources (e.g. http://syncapp.bittorrent.com/1.3.77/) Unpack the binary somewhere Overwrite the binary installed by btsync-common (in /usr/lib/btsync-common) with the binary you unpacked If you have installed on a i386 machine, you should take in consideration, that in /usr/lib/btsync-common there are two binaries - you must download, unpack and overwrite both)This solution is really DIRTY. And remember: the next update, will overwrite the binaries...

Ladies and Gentlemen, and again I'm pleased to announce a new version: btsync-gui (0.8.2-1) unstable; urgency=low * Added Bulgarian translation by Atanas Kovachki (Closes #121) * Added Polish translation by Damian Szymański (Closes #123) -- Leo Moll <leo.moll@yeasoft.com> Sun, 06 Apr 2014 18:28:06 +0200

Hi antimojv, first of all: The directory /usr/lib/btsync-common/.sync should not exist. The reason it exists on your system, is that you have started the btsync executable from this directory without any paramters, which should never ever happen. The process is managed by the daemon scripts and you should NEVER start the executable manually unless you know exactly what you are doing. The problem is that the executable tries to startup against all odds and if started without any valid configuration file, it starts with a default configuration and creates its storage_path under the directory the executable is located. And now let's clean up this mess: First kill all btsync processes that may run in background from your previous tests: sudo pkill btsync-coresudo pkill btsync-daemon Then delete the unwanted storage_path: sudo rm -rf /usr/lib/btsync-common/.sync Now you have a clean system. The storage_path used by the default instance created by the server packages is located in /var/lib/btsync I have no idea, if you are talking about the default instance created by the package installation routine or you are using an instance defined by a custom configuration file. In any case you have to create the debug.txt file in the storage_path of your instance. If you are using the default instance created by the package manager, you will create it this way: sudo echo FFFF > /var/lib/btsync/debug.txt After that you should restart the daemon with service btsync restart and then you will find your log file in /var/lib/btsync/sync.log

Thanks to Damian for the Polish translation!

OK - I will add in the startup script a workaround that will modify the permissions of all files in the storage_path to 0600 - This unfortunately is only a workaround but it should in any case increase security...

Thank you a lot! It will be available with the next release. Short status update: btsync-gui incomplete translations: Catalan (0%)French (95% - only 4 strings missing!)Greek (10%)Hungarian (0%)Polish (0%)btsync (server) incomplete translations: Catalan (77% - only 14 strings missing)Chinese simplified (77% - only 14 strings missing)French (93% - only 4 strings missing)Greek (93% - only 4 strings missing)Hungarian (93% - only 4 strings missing)Polish (93% - only 4 strings missing)Spanish (93% - only 4 strings missing)

A user reported the following problem in Issue #122, and I agree with him: In my opinion there is no real workaround for this: setting an UMASK that prevents this, affects also the shared folders.

If it does not interfere with the normal operation of a standard installation of BitTorrent Sync, I'm available for testing (2 x Mac Mini with Mavericks, 1 x MacBook Pro with Mountain Lion)

Ladies and Gentlemen, enjoy this new version! As usual Launchpad will take longer... btsync (1.3.0-1) unstable; urgency=low * Added support for the new 1.3 advanced settings (Closes #120) -- Leo Moll <leo.moll@yeasoft.com> Thu, 03 Apr 2014 14:14:58 +0200

Is there any project page with some more information available?