kos13
-
Posts
750 -
Joined
-
Last visited
-
Days Won
92
Posts posted by kos13
-
-
I just checked with the team, we do have an issue with confirmation email. You are subscribed but without confirmation email for now.
-
Then could you look into it please?
I used the same email address I'm using here. The subscription page says I'm on it (droid), but I didn't recieve anything.
Interestingly I get newsletters and stuff from no-reply@bittorrent so my emails are working.
I'll check that.
-
Do you have any PC that goes to sleep? We do have the issue that files are moved to trash when computer is woke up. There are also few bugs that were fixed. Please wait for the next build that will be released soon.
Sorry for any inconvenience.
-
Could you please follow steps here and refer to this thread in your email?
-
Are there confirmation mails sent after subscribing like someone quoted earlier?
I subbed to android yesterday and still didn't recieve anything - if it's a manual process then forgive my impatience.
yes you should get confirmation email.
-
Since we are limited to a 100 test users for iOS (thank you Apple) I would like to make sure that all contributors to the forum will get invitations. Please reply to this topic and I will make sure that you are included.
If you need Android application, subscribe to the list. We don't have any limitation there (thank you Google)
EDIT: If you are lucky to have 5GHz WiFi on your mobile, consider upgrading your WAP to support it. Sync will squeeze every bit out of it.
-
Be one of the first to test the new Sync mobile apps.
Android and iOS applications are being developed for BitTorrent Sync. We need volunteers to test (and break) these new apps and provide feedback. Interested?
Currently in private alpha. Request an invite below:
-
Seems like a bug. Can you tell us OS and Sync versions?
Sync should have only FILE_1.!sync, it will get pieces to this file, irrespective of network up/down and sync up/down, exactly like BitTorrent client. Once file is completed it should be renamed to FILE_1
Yes, Sync resume any transmission and has some policy for effectively transmitting files between peers. Amount of the files in transmission is decided by size. At the moment Sync can transfer in parallel from 1-3 files, we will add configuration later.
-
If there will be an effective way to find a collision on 160 bits fully random key, there will be much bigger security problems than Sync.
Keep in mind one more thing, unless this is targeted attack, you will need to send and receive UDP packet to verify collision. It naturally adds 5-10ms for each key not mentioning requirement for the network and CPU. CPU and network will throttle any brute force attack at once.
Sync secret approach is by far more secure than any login/password and secret question approach. It is just not get used by mass market. We do take this pain to explain this solution to people, since this is a right way. It is much easier to implement login/password based approach but it is so insecure, so we don't want to take responsibility by providing bad security for your data.
Final question, would you replace 160 bits random string with YourLoginThatIsEasyToGuessWithSomePasswordYouBelieaveIsSecure string?
-
We need logs, this is too generic description. Please follow
-
We do need logs, could you please follow these steps?
And you use 134 build, right?
-
We are looking to this problem. It is recorded as a bug and we will fix it.
-
We do need logs. Could you please follow these steps
-
We need logs, from this part of the log we can't say anything definite. Could you please email us logs from both machines. Email syncapp@bittorrent.com
-
Regarding the simple use case I used to open this thread, could you answer me simply if you believe this needs fixing and if it will be fixed in a future version ? This is quite a common scenario in our environment and I probably won't continue testing btsync if I know this will stay this way.
You constantly add folders with new secret to the Sync in your environment? If so, could you please describe this use case in more details, so we know how you are using Sync. The problem you described comes from the fact that you have added new folder to the sync with the files.
We constantly improve Sync and your use case is recorded as a bug. Unfortunately I can't give you any timeline for the fix.
-
We know this problem, please wait for the next build. It will be dramatically better.
-
Have you deleted one shared folder on this computer?
-
It is much better if you have local clock synchronized, which is an actual right way. Sync will deal with the case if clock is not synchronized between computers, but this will complicate things a little bit.
Answering your question: Sync will behave correctly if your clocks are not synchronized, it will detect these cases.
-
Aha, if one node copies an older file over an existing file and the timestamp of that file is older than the timestamp of the last completed syncronization: This is no conflict?
Of course this is not a conflict. You just replaced file with older version that needs to be propagated across all devices. If files are different and have the same timestamp - then this is conflict, since you don't know which version you want to keep.
OMG. Seems that I need to remove BTSync from all my machines. We have lots of use cases where old files are put into the game again. Now I do understand lots of the problems I've seen in the past ...
There were bugs and we are fixing them, if you have any specific use case please report it to us.
In addition: BTSync itself behaves different in some situations. If you copy a file over an existing file and this file has the same content you don't copy this file, you don't even attach the new timestamp the the existing file on other nodes. So you produce files with different timestamps. I can't imaging what problems will arise from that ...
Copy operation means, that first you remove the original file, then you create a new one with the same content. It will have a different timestamp that is set by OS (nothing to do with Sync) and Sync will detect that content is similar just changed timestamp, so this information will be propagated to all nodes. I don't see any problem here, or I just don't understand what you are tying to say.
-
Sorry for buttin in:
This is a true conflict. In that case both files should survive. The new and older file should be synced with a comment (e.g. "1 (conflicting version from node xyz).txt".
Unfortunately this is not a conflict. You have two files with different timestamps, so Sync needs to choose oldest one and overwrite with newest one. Of course this will work only if we work with timestamps only. Then you would like to detect this as conflict, you will add something like - file was synchronized at 10:50 May 29 and if timestamp of the file is older than that - this is conflict. But next you need to keep in mind that you might have different peers, different synchronization time for each peer and each file.
Pure conflict is when two files have the same timestamp but are different.
-
Please expect significant improvements in metacache in next builds.
-
... slightly different configuration than normal...
That doesn't mean "turned off" does it? 
Performance wise it is very close to "turned off" if you compare it to BitTorrent super-seed mode. You do want to have a supernode for a fast file distribution inside the LAN, where all nodes have the same connection speed. When you will have nodes with different speeds the fastest distribution strategy is different.
We will continue improvement in this area, but most likely it will become a part of configuration. This way you could adjust the strategy for your needs.
-
It is implemented, but has slightly different configuration than normal BitTorrent client. We will see how we could improve that.
-
Sync uses timestamp of the file, when it was added to the Sync directory. I.e. when you add folder to the Sync this time is treated as timestamp of the file. Sounds complex, but there is one use case why we did it this way.
Assume you have file 1.txt with timestamp of May 28. It was synchronized across computers. Then you move the file 1.txt inside the Sync folder and this file has timestamp May 26. If we compare only timestamps, May 26 will be overwritten by May 28 file from other computer. And this is not what you would expect.
That doesn't mean "turned off" does it? 
is it possible: sync only to and from central server?
in Sync General Discussion
Posted
This feature is on our list, since it makes a lot of sense. However we have a long list, so I can't say when we will be able to implement it.