Swisstengu

ok - indexing is running (fast) right now - we will see if this solves the problem. @dantounet: how many files do you manage through sync? Maybe we (or I) reached some limit somewhere? Cheers, C.

Hello, I'm doing some load-test with Sync: ~340G, dispatched in 149k+ files, with recursions (more than 10 subdirectories) I'm wanting to sync those data from one host (call it "master") to two others (call them "slaves"). At the begining, Sync seemed to work as expected, syncing data and so. Then, after about 6G of transmitted data, nothing seems to move. I enabled the debug, and found out many errors, like: Torrent magnet (…HASH…) status:137 error:<NULL> meta:0 conns:1 io:0 What does it mean? Thank you! Cheers, C.

Hello, Same problem in here - and it seems to prevent Sync to work normaly - I have about 340G to sync (from a "master" host to 2 "slaves", and it did only 6.8 on one, 6.2 on the second… These 340G represent about 149541 files (yes, that much… And this is only a part of the directory I want to keep sync-ed between 20 hosts once it's in production). I don't know if both problems are related. Cheers, C.

By the way, it's maybe even better to download from the generic link: http://btsync.s3-website-us-east-1.amazonaws.com/btsync_x64.tar.gz This way, you just have to provide the architecture, and Voilà. Some md5sum check would be of some use in order to not stop btsync for nothing. This would mean: - uncompress in some temporary directory - md5sum of the newly downloaded btsync binary, compare it with the current one - IF md5sum aren't the same, do the update - ELSE discard the update, and try it again the next day. That said… the best way would be to have distro packages (.deb, .rpm, .ebuild and so on) in order to get a fully system integrated update. Cheers, C.

Hello, Instead of the killall, it may be better to use some init-script. I did this one on my Debian computers/servers: #!/bin/sh # Largely adapted from xdm's init script: # Copyright 1998-2002, 2004, 2005 Branden Robinson <branden@debian.org>. # Copyright 2006 Eugene Konev <ejka@imfi.kspu.ru> ### BEGIN INIT INFO # Provides: btsync # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: # Should-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop the SLiM daemon. ### END INIT INFO DAEMON=/usr/local/bin/btsync CONFIG=/etc/default/btsync DAEMON_OPTS="--config ${CONFIG}" STARTAS=<username> case $1 in start) su -c "${DAEMON} ${DAEMON_OPTS}" $STARTAS ;; stop) kill $(cat /tmp/btsync.pid) ;; *) echo 'Usage: start|stop' ;; esac # End of file Smarter, and this allows Sync to start on boot . The equivalent for Gentoo computer: #!/sbin/runscript depend() { use net } start() { ebegin "Starting btsync" su -c "/usr/local/bin/btsync --config /etc/btsync.json" <username> eend $? } stop() { ebegin "Stopping btsync" kill $(cat /tmp/btsync.pid) eend $? } With the location, you may as well use this command line for tar: tar zxp <archive> -C /usr/local/bin/ As for the URL, it may be better to fix it in the script, and just pass arch and version as arguments. Modified script would look like: #/bin/sh if [ $# -ne 2 ]; then echo 'Please provide architecture and version' exit 1 fi arch=$1 version=$2 url="http://syncapp.bittorrent.com/1.1.33/btsync_${arch}-${version}.tar.gz" wget $url -O /tmp/download.tar.gz tar -xzvf /tmp/download.tar.gz -C /usr/local/bin/ || (echo 'ERROR: unable to download' && exit 2) service btsync stop rm -f /tmp/download.tar.gz service btsync start Cheers, C.

Hello, My guess: you may have multiple instances, as long as they - don't have the same PID file - don't use the same port - don't use the same data directory (default ~/.sync) - don't sync the same directories This kind of setup may be good for a multi-user use - else, a single instance with multiple directories is far better.