Camaban

Probably worth remembering that once the initial sync is done it's done. Then it's only the new stuff, which unless you're adding vast wads of files will take no time at all.

I'm fairly sleep deprived here, so my apologies if I misread something. But to ask a stupid question - Did you use sudo when changing the permissions?

What range of file sizes? IE: Is it lots of little files?

Yep, for wifi that actual throughput is quite reasonable. Although if you need more, you might like to keep an eye out for the new 802.11AC and upcoming 802.11AD devices.

His problem is probably one of quota than one of actual bandwidth.

All devices are 1.1.15

Really though, unless files are updating *all the time* then it shouldn't make a difference to the bandwidth usage.

Keep in mind it'll only update what's changed. Although you could get it to watch a folder, then rsync stuff to that folder every six hours instead of having it watch your main data dir.

This. Exit the program or kill the task, re-start the program on the Windows box only (Ubuntu and CentOS boxes are fine) and it works for anything up to another few hours without a hitch.

>>Perhaps i think there's some optimization capability<< There's always room for improvement there. The current version is massively more efficient than the first versions were. >>Anyone can say how i could check speeds with another data transfer method as a reference.<< iperf/an mutually compatible available for your OS's? >>mean when i could test with another data transfer protocol as ftp or samba and get higher speeds the conclusion could be that there's some possibility to improve btsync speeds.<< At the very least it would be interesting for finding out what your network is capable of. It wouldn't be hugely useful for figuring BTSync speeds (again keeping in mind that how many files and how large they are makes a huge difference) My advice for the moment though would be to keep waiting for newer versions. It's noticeably improving all the time.

That's reasonable, particularly if there's lots of little files rather than a smaller number of huge ones. Additionally, the speed you've given for your device is a speed you'd expect to see on an 802.11N device. So I'm assuming you're transferring over wireless. 300mbit is certainly not the speed of any wired network device I've ever used. It would be 100mbit or more likely, 1gbit. If so, that 300mbit is a foolishly optimistic theoretical best case. Real world throughput is closer to 100mbit in ideal conditions. Which means a maximum transfer rate of 10mBps. So if that's the case, your speeds are quite reasonable.

Here we are. Link to the logs. 777MB uncompressed, so can't attach here. https://dl.dropboxusercontent.com/u/17266982/sync.rar If I can get more information, please let me know.

On a more positive note, when it is transferring it absolutely flies, even when dealing with large amounts of small files. Massive improvement from before.

I've noticed this. If I were smarter I'd have started debug logging sooner. Will submit it once it's done. Only seems to be the latest version. It behaves as if it's simply finished syncing. When BTSync is restarted, the sync restarts perfectly. This is for about 330GB in 204k files. Windows 7 box w/ 12GB RAM syncing between an Android device, a Ubuntu 12.10 server and a CentOS 6.4 server. The latter two with 512MB of RAM and for reasons not even really known by me, all x64 (Really don't know why I set it for the two Linux boxes)

I'm on AOKP JB 4.2.2 but hopefully this is close enough: Settings Applications/Apps Downloaded Select App Untick "Show notifications"

Grab a program called Greenify. It made an utterly huge difference on my slightly overloaded Galaxy Nexus. I actually have free RAM now.

This can be done under the Android app settings. Have a look around, but you have the option to remove the notification icon from almost anything. It'll still logically be there (IE: The app and OS will behave as if it's there) you just won't see it.

Similar to a backup. A backup also takes user error, etc into account. Ideally has versioning, etc. Anything that immediately replicates any mistakes isn't seen as a backup. However, for what you're after (Or I'm after, for that matter) I doubt you care about the technicalities

Cyclic Redundancy Check. It's worth reading up on. Long story short, it allows for detection of accidental damage. It's one of the reasons you're able to transfer a multi gigabyte file from one side of the planet to the other over dialup apparently flawlessly. And yes. There might be lots of other things that could cause dodgy outcomes (Check your .SyncTrash folder if you think this has happened) as this IS alpha software, but something like physical hard drive corruption is not one of them.

Normally when a hard drive crashes, you don't get changed parts of files, but the file itself (or the entire drive) is completely unreadable/unusable. Look up CRC to find why this is unlikely to be a problem for anyone. But as Zbig says, this isn't a data backup solution, it's a synchronisation solution. It might be good enough for the vast majority of people's requirements, but they're still very different things. You could also have a look at what version control software could be used with this.

Yes. I normally use rsync for the initial dump and then BTSync for everything following that.

Possibly a bit different: Remember, with a network drive, you might have it opened in two places simultaneously. Not possible with this. You've got one copy that gets copied around when you edit it. I've never tried anything similar with endnote, so I'm not sure how it'll work on that, but thinking of it that way does make sense.

What you're trying to figure out. Unless there's something more complex there I'd missed. Such as (on re-reading it) that you're wanting something that'll do this on iOS.....

Doesn't the read-only share do this?

On this, has anyone noticed that it sometimes incorrectly reports how much needs to be done? IE: I've got five shares. All of which are (in reality) synced. However, one shows 18.7GB remaining, one shows 2.3GB and one shows 2.7GB Probably caused by the other end incorrectly reporting how much it has stored in its directory. This really seems to happen on RO syncs. However, if I copy new files to the directory, it picks them up and syncs without a problem. Source end is Windows 7, Destination end is SLinux 6.4