Xanza

This must be an issue with your connection then. Pretty much the same thing happened to me, except when I clicked on each item they Synced (because they wouldn't automatically) with no issues. Visual: As you can see, the Sync finished, I added a new folder on my phone, captured the QRCode and clicked on some items to manually Sync them. Here they are complete on my desktop:

I'll begin looking into this.

Not sure if this is already suggested, but as discussed in this thread: http://forum.bittorrent.com/topic/20458-more-info-about-read-only-mode/ Read-only keys (all for that matter) should have the option of 'resync' to ensure all contents are up-to date via manual action.

Not necessarily. With read only access you might only want, or need access to one or two files out of thousands. Therefore you can simply remove the other files that are not needed and only sync the few that you do need. But there definitely should be an option to resync the folder.

This is incorrect. The actual official BTSync.exe program is being picked up as "Trojan-Ransom.Win32.Foreign.diwl" from Kaspersky and "TROJ_GEN.F47V0608" from TrendMicro HouseCall. Also, just for clarification, I downloaded this exact file from the BTSync page and tested that file, not the one I currently have. So these findings are legitimate. Therefore it's up to a BitTorrent representative to contact these virus vendors to correct this false positive.

It's just as simple either way -- however, because of the extra option, those that don't have access to wget or curl will be able to install the packages as well. This method was not implemented because BTSync was difficult to setup and use, but simply to keep the system ubiquitous and usable by all under any circumstances.

There's nothing that I can think of that would disable this feature -- it's simply the way that BTSync is able to check the service to see if there are new files to download; hence, 'It's simply the way the program operates' would be the answer for right now. As the lifecycle is still in alpha I'm sure something could be worked out for ARM based NAS in the future -- however, I don't suspect anything would be worked on for a long time (~11-12 months).

I've had massive success by using Docker and BTSync. With it I'm able to spawn my clients own BTSync instance that they're able to fully control.

This is the nature of read only keys. Because the content is downloaded, machine B is obviously able to remove the files from their local hard drive, however the chances are not synced back to machine A, hence the 'read only'. Therefore, if you have machines 1 - 5 you could have write permissions only on machine 1, with 2 - 5 having read only permissions and only machine 1 would be able to syndicate changes between all 5 machines. Also, to force a re-download of the content, you would probably have to remove the share, then re-add it and having to re-download all files and folders again.

If you're looking to pass encrypted content to and from devices, BTSync is not what you're looking for. Try looking into FreeNAS, which offers Sync clients with the option to encrypt.

This would be a really strong use case and should be documented by both those testing the method, and BTSync themselves. You guys should definitely collaborate -- never know when you'll be able to get 4k simultaneous users again (at least while in beta).

Android, please and thank you.

Which is why I would not attempt to break encryption, only 'guess' encryption. I know the characters (a-zA-Z0-9) used, and the range of characters (28-35). It would be much quicker to use 97,510.4 GHz of processing power (~3.2*30,472) and the 27TB of RAM paired with the 2PB HD to set dictionary of hashes instead of attempting to figure out the specific algorithm used to generate the hash. Granted you'd never be able to use all 97,510.4 Ghz effectively, however, you'd be able to do a lot more side-by-side processing which would help your end result. Again, granted, this is all dependant upon being able to quickly test said keys for validity. IMO, however, BTSync would be much better off with a SHA-512/384 private key and SHA-0/1 public key -- but that's just my opinion.

Sounds like a permission error. Try killing btsync and restarting with root permissions. If it's able to run after that, then you've confirmed it's a permission error; in which case you would need to ensure that the files and folders are read/writeable under the username in which you're spawning the daemon instance.

The shits still in beta, what the heck did you expect? I think it would be beneficial for you to take a look at the software development life cycle: http://i.imgur.com/tey3q22.png (This might sound haughty, but I think it might give you a concept of the issues that the Sync team is dealing with here). I've been apart of the open source community for almost 10 years, and I can tell you from experience, not everything benefits from being open source, especially an application such as this. Mainly, because people attempt to use tools like this for something other than it's intended purpose, eventually making the project outdated and defunct. When you have a team of dedicated developers working on a single project model and taking requests from an active community you get much more success with a program like this. (7 years IT Project Management talking here). Welcome to the digital age. That's what enterprise in this day and age is. I mean look at what you're doing, you're browsing the Internet using a network operating system that you've purchased to run the machine that you've purchased to use the Internet that you're consistently purchasing. You go to the store and purchase groceries, come home and use your stove that you've purchased while using electricity that you're consistently purchasing to make food to sustain your life from the groceries that you've purchased. You go to a car dealership and purchase a vehicle, go to a gas station and consistently purchase petrol to power your vehicle that you've purchased. Just because you own end devices doesn't mean that you own everything in the middle -- in all three examples above you're purchasing both electric (or gas), Internet, and petroleum from third party providers. That doesn't mean that it would be better for you if you had to run to Saudi Arabia to mine for petrol to power your car. Just food for thought.

CEHv7 here -- let me share an industry secret with you. Security is nothing more than blanket on a cold night in most situations. There is usually a way around every type of security, even strong entropy. Realistically if a process could be developed to 'test' keys for validity this entire program would become obsolete (the way it's designed currently) immediately. Any person can rent a supercomputer from Amazon (AWS) and would be able to run yottabytes of hashes per minute. For anyone that doubts me, consider the specs: 3,809 Octo-Core Processors (30,472 total cores) 27TB of RAM 2PB of Storage Sure, it would cost you $1,279 per hour to use it, but with that kind of power (30th most powerful supercomputer in the world at those specs) it would only take you an hour to find a massive number of keys (maybe thousands) -- even with strong entropy. Granted this situation is only viable if someone were to develop a way to 'test' keys for validity; I'm merely saying, if nothing is done about this single key system, this program will quickly out-date itself. However, for testing purposes, and for general use (syncing simple paperwork, school work, MP3's) this program meets the mark and works fine. Just don't store banking information in your Sync folder and you'll be fine, even if there is a breach.

To all of those running NAS who seem to be running into this issue, I would attempt to reinstall glibc, remove BTSync and all of it's files, re-download and attempt again. ./btsync: relocation error: ./btsync: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference I can't be too sure without playing with the device in front of me, but it would seem that maybe the version of glibc that comes with these devices could be outdated. The latest version is 2.17. ldd --version Run the above command to version check.

Backup photos from my Ubuntu pc to my Windows pc | NO Sync my documents over several pc's | YES Sync my music from my pc to my android phone | YES ​As stated before, BTSync is NOT a backup solution, and should not be used as one. It's meant to be a Sync client -- hence the name. However, for Syncing your documents, and music, this is pretty much a perfect solution.

I honestly don't see how you can blame a program for settings that you've given it to run on. This post is quite literally tantamount to blaming Microsoft for you as the end user enabling the "Don't move files to the Recycle Bin. Remove files immediately when deleted." option under Windows. That aside, I've yet to experience this issue. I've only just (right now) updated my client to the newest version (I have auto updated disabled). So I'm really not sure why you're experiencing issues. However, I can tell you that until BTSync is out of beta you should NOT disable the Sync trash option.

To make this a bit more ubiquitous in the community I've added it to Github via Gist: https://gist.github.com/Xanza/5692817 Thanks for the effort, Tux.

To make this a bit more ubiquitous in the community I've added it to Github via Gist: https://gist.github.com/Xanza/5692812 Thanks for the effort, Tux.

The only suggestion that I could supply is to run the client from Windows 7 with administrative permissions and attempt to run the debug once more. Windows might not be giving the client adequate permissions to be able to save the sync.log file.

I was about to say, it's probably an issue with your router. The BTSync client isn't something that you can simply modify the number of connections with -- so basically it's a hardware problem and you'll have to upgrade to fix the issue. Your router is simply too old.

Idle CPU usage is pretty stable -- but once you begin to upload and download I've used as much as 2.4 GB of RAM. For me, with a total of 16GB DDR RAM that's not even 1/8th of my RAM, so no big deal there.

I honestly don't believe BTSync is the problem here. I've also tested this on my Raspberry Pi and have also received this issue: http://forum.bittorrent.com/topic/18634-very-inconsistent-speeds/ It would seem it could be a hardware issue, meaning the Pi is just not powerful enough to sustain consistent speeds.