Xanza
-
Posts
102 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Xanza
-
-
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.
-
Looks like you have an existing infection in your machine, unrelated to BitTorrent Sync.
Whilst I can't find specific details for the ".diwl" variant of "Trojan-Ransom.Win32.Foreign", for all other "Trajan-Ransom.Win32.Foreign" threats; "This Trojan arrives on a system as a file dropped by other malware or as a file downloaded unknowingly by users when visiting malicious sites." (Source)
Therefore, this infection has not been caused by BitTorrent Sync itself!
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.
-
I don't get it, what could be simpler, a tgz file with two files in it, one a license file. You create a config file, if you want, then secure the login and you are just about done. Autostart if you need it, but if you've got a server that never stops, then neither does btsync. It's about as simple as you can get. Automating startup is trivial for any sysadmin and not much harder for non-sysadmins.
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).
-
That's exactly the way I use in Linux versions installed with the new DEB packages. There is the possibility to run more than one btsync instance by spcifying more than one configuration file. Since BTsync provides no direct way to specify the credential it runs under, in Linux I supply this information using the naming of the configuration files (e.g. /etc/btsync/myconfig.leo.json). In windows you can create more than one service running under different credentials (you have only to name each service with a different name). The only problem is probably that btsync for windows gets his configuration from the registry. If btsync uses the HKEY_LOCA_MACHINE registry hive (that should not be allowed for user-software, since it requires administrator rights to write there), there is no chance, but probably btsync will handle it correctly by using the HKEY_USERS hive and keeping the configuration separated for each user. This would permit you to install one instance of a service per user since each user has its own configuration storage.
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).
-
Your subscription to our list has been confirmed.
Android, please and thank you.
-
The machine you mention is tiny compared to the sort of machine that's needed to defeat the encryption used by BTSync. The normal aim for modern encryption is to defeat Maxwell's demon, ie use the basic laws of thermodynamics to calculate the sort of brute search that could be done (ignore the cost of testing for a match, it's not relevant) if the 'computer' were perfect.
That's why BTSync's default key length was upped from 128 bits to 160 bits. With a 128bit key it would just about possible that somewhere in the universe there are two identical random 128bit numbers; if the universe were entirely made of random numbers.
With 160bits you need (a large) multiple number of universes.
But in one way you're not wrong; idiots and rubber hoses will both trump maths books.
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).
There is something very frustrating about owning the hardware on both sides of the sync but having the pipe between them be controlled by a 3rd party.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 referenceI 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 --versionRun 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.
- Backup photos from my Ubuntu pc to my Windows pc | NO
-
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.
Bug with Android App
in Sync General Discussion
Posted
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: