Xanza

You would have to detect the operating system of the client, and if it's being transferred from Windows to (l/u)nix then you could attempt to save it as root, but that would probably require that the BTSync daemon was spawned by root.

Because you're routing the traffic through a VPN it's possible that the firewall on the VPS is blocking the ports necessary for communication. You shouldn't immediately blame the service before you know what the issue is... Remove the VPS, and test it on your open, un-proxified network first; then make assumptions as to the issue if it still doesn't work. Also you should NEVER assume that you know what an issue is, especially because of your profession. That's ignorant and makes you look ignorant. Besides, you repair PCs, you're not a network administrator.

I'm using the official Raspbian wheezy build -- once I get home tonight I'll check free memory while transferring a larger file, but I'm pretty sure I did already and they were between acceptable parameters. But to be sure I'll test it again.

Yes, BTSync consistently uses anywhere between 10-70% of the total CPU power of the Pi unit, however, it never really reaches 100% -- so I don't believe that's the actual issue. (I've monitored during transfer with htop).

I'm gonna post this in hopes that anyone who wants to put Sync on a Raspberry Pi might see it:

To expand upon that idea, why not just create another .SyncSums file or something that calculates the total MD5 (or SHA1 whatever) sum of all files located within the directory tree that are set to sync. Then simply compare this single MD5/SHA1 hash between clients, if it's different, then something has changed, if it's the same, then things haven't. Would probably work a bit better than polling every XX seconds with a real time analysis of whatever is in the directories. (which will probably get VERY slow as you accumulate a ridiculous amount of files (100,000+). Any thoughts?

Thanks! I'll give it a shot and let you know -- everything seems to be working and I'm not receiving any errors, but a simply symlink won't hurt. EDIT: I guess not. EDIT: Tried running btsync as root -- same issues. Any transfer that takes longer than 10-12 seconds drops down to near completely stopped, or completely stopped. SEMI-FIXED: This issue was caused by the default Raspberry Pi settings. By default the partition size of the disk is only 1.8GB to which I filled up VERY quickly. After attempting to transfer a larger (700MB) file, the transfer peaks at 2.8 Mbps (pretty much my speed cap) then drops all the way down to 20 Kbps, then down to 12 Kbps, then finally down to 0 Kbps. Before: After: Read More: http://www.ardupi.com/2013/01/raspberry-pi-raspbian-no-space-left-on.html All in all, the transfer speeds for smaller files are fine now, but again, anything that takes more than 10-15 seconds to transfer basically drops to a speed where it almost stops. Any suggestions?

Start over. sudo wget http://btsync.s3-website-us-east-1.amazonaws.com/btsync_arm.tar.gz ; sudo tar xvf *.gz ; rm -rf *.gz ; ./btsync --dump-sample-config > sync.conf Execute that whole command via SSH, it'll re-download the ARM version of btsync, unpack it, remove the tar.gz file, and dump the sample config to the console. After that, you should be able to setup the config the way that you want and then: sudo chown u+x ./btsync; ./btsync --config sync.conf And it should work just fine; at least it did for me. You might have downloaded the incorrect version of btsync (you need the ARM version).

I've installed and configured btSync on my brand new Raspberry Pi and I have to say it's working great, however, I just tried to transfer a 115MB file into my backup storage (on my Pi; 8GB SD Card). The transfer starts at about 2.2 - 2.8 Mbps for about 10 seconds, and DROPS down to 0 Kbps. Then jumps between 30 Kbps and 0 Kbps until the transfer is complete (about an hour). As you can probably tell, this is pretty crazy, and not efficient at all. Upon inspection of the BitTorrent Sync application, under the "Transfers" tab, I can see my file "flashing" within the window. When the file is in the window, obviously it starts to transfer, then almost immediately is removed and the transfer drops to 0 Kbps. Anyone suffering the same symptoms?

I've experienced quite the opposite -- I've been able to transfer files that are locked by the operating system.

I'm going to assume that you're using WAN as a colloquial for wireless area network instead of it's correct abbreviation for wide area network -- assuming that, ensure that you have NAT turned on and correctly configured with universal plug and play. I have Sync installed on a local instance of Raspberry Pi running via Cat5e and I've been able to transfer 8GB of information (limited by the size of the SD card) in less than 2 minutes.

Thanks, useful info right there.

The ability to set capacity caps for a given folder via the API would, I'm sure, a very highly sought after feature. Use Case: (hypothetical) I have a dedicated server which I use for backup storage -- a friend would like to use my online storage server as well. I agree, but I'd only like him/her to use a maximum of 1GB of storage space. Using the API, I should be able to set any given folder which is attached to his specific secret key, an (admin) set maximum storage value. This is a highly useful feature when thought about at length.

Not only is this information wrong, it's kinda stupid to say that you can 'crack' these secret codes, but the more secure option would be to store said keys in a single location... lol If you would have said 'guess' these secret codes, then yes, I'd agree with you. But considering we're unsure yet how the secrets are generated, that's an improper assumption. Not to mention, if the system uses something as ubiquitous as unix time-stamp for example and a variation of other box specific notation, it would be neigh impossible to decipher the secret to begin with. I genuinely support the idea of a private, and a public (or secret) key, or if you fancy the wording better "Two secret keys." Base the key generation off of two separate algorithms, and off of misc or garbage information, and it would make even a single key very difficult to replicate. It would also ensure that someone can't simply generate a gargantuan list of possible secret keys and test all of them for valid secret keys, thereby stealing everyone's files.