sfmcnally

That's not really true. btsync has the option to have one or several of the nodes be encrypted read only untrusted nodes that only send and recieve encrypted versions of files that are then decrypted on devices that have the master key or non-encrypted read only key. If you search the forum for encrypted node you will find instructions. That said, since 1.4 was released, I've had a hell of a time getting anything to sync correctly and consistently, encrypted or otherwise. This thread explains it pretty well: http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/

Can someone explain what each part of this line in the log means? I'm assuming conns:0 means that there are no peers connected. Is that true? So I guess I have several questions: What does status report and what are the possible values returned? What does error report and what are the possible error codes? What does meta report and what are the possible values? What does conns report and what are the possible values? What does io report and what are the possible values? If any of you know can shed light on one or all of these it would really help me out. Thanks!

My family and extended family had been using btsync as an encrypted distributed backup system. It was working flawlessly up through version 1.3.109. Each of us had a local backup folder and we distributed the read only encrypted backup key to the other members of the family. Everyone had an encrypted copy of everyone else's data but had no direct access to the data as we each kept our own Master Key a secret. It worked perfectly on Windows 7, Window 8, and a Synology Diskstation for nearly a year. Version 1.4 Broke everything. All the folders report the wrong size, the machines no longer sync, the number of peers is wrong, the software is not downgradeable, and it's generally been frustrating in every way. I would like to help fix this problem, because I really liked the idea of btsync and it's potential, but the list of bugs is so long that I don't even know what to email support about. I don't even know where to start. I hope this is not the direction of btsync in the future. I for one won't be a user much longer if things continue down this path. Thanks for all the hard work, but please reconsider the direction this program is headed. Have you considered open sourcing the code and allowing community contributions?

I have a list of files that won't sync now. They all start with -$ and then a filename. I don't see these files in the folder btsync thinks they are in. I have no open files, so that's not the issue. Is this part of the known bug where filenames with certain characters don't sync? It seems that overall this version is slightly better than .83, but still buggy. One peer reports that it is fully synced and the other lists files awaiting transfer. Sizes are still misreported on some folders. Some folders show a size of 0. Thanks for making this version a little better than the last version of 1.4, but 1.4 overall seems to be a drastic step backward. Why did the sync engine get so buggy just because the front end chagned? Shouldn't the UI be independent of the backend? I still have high hopes for btsync (nothing matches the speed), but I currently have 0 confidence that I my data is correctly syncing across all the nodes.

Despite this being wrong, you are lucky that you didn't. Stick with 1.3 for a while.

This version is so buggy it makes me want to cry. Encrypted nodes got broken. Sizes are reported wrong. Some files don't sync. One node says synced and the other has files waiting to send or recieve. Not backward compatible. This is a pile of mess. I think I'm gonna have to go back to 1.3.109 and resync all my data. Are you guys aware how terrible this 1.4 version has been out in the wild. I'm pulling my hair out. Thank you for the software, but it is irresponsible to release a quality product that people come to rely on and then push out an update that totally wrecks the system. I have 4 nodes on Windows and linux all over the country and I can't begin to tell you how frustating this is. Please take testing more seriously before you release updates. Thank you.

The new build didn't upgrade the old build for some reason. It installed a second version of btsync. These 1.4 builds have given me nothing but headaches. I can't tell if anything is syncing anymore and the reported sizes are all wrong. I'd downgrade back to 1.3 if it didn't mean starting over. I appreciate the work devs, but 1.4 was too buggy for release.

I am running BTSync on a windows 7 machine, and it is syncing about 200k files. The longer version 1.3.105 runs, the more ram it uses until an eventual crash. This happens every other day or so. The user interface also slows down the longer the program is running. This was not an issue in the 1.2.xxx versions I used. Currently the program has been running for 24hrs and is using ~1.5gb of ram. This is much higher than the estimates that I saw in the FAQ for the number of files I'm syncing. Any help is appreciated.

It is easily reproducible. The longer the program runs, the more ram it uses until it finally crashes.

I am also having this issue on 1.3.105. I'm syncing 4 folders and 200k files with a size of roughly 230GB. CPU load after 1 day is ~30% and the memory usage is way higher than the stated 400bytes per file. It's using about 1.5 gigs of memory after 1 day and eventually crashes.

It seems like you guys would benefit from the info in another thread. You don't have to have an API key to generate read only encrypted secrets. I have several encrypted untrusted nodes running using the instructions found below. http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/