dswd

I also disagree. I am working with synced git repositories for a few months now and had no problems so far. On the other hand if you sync the working directory but not the .git folder there are lots of possible problems: - Whenever you commit on one node you cannot update other nodes because they already have the changes and do not want to overwrite them. - When you check out a different branch on one node all other nodes will get those files too but still think they are on another branch and see lots of changes. As a consequence you should either sync the working directory and the metadata or none.

Ok that is interesting. The packets are broken in a very special way, the length field in the IP header is correct but the length field in the UDP header is off by 4 bytes. That either means that you have something in the network that chops off 4 bytes and corrects the IP header but not the UDP header or somehow these packages are corrupted while being sent. Looking at the packet contents it seems that there are actually 4 bytes missing and I think the last byte is "e". Are you capturing the packages at the source or somewhere else in the network?

There is a button called "Add Folder". BTW: Poor Tux...

To be fair: Encfs has the same problem

No, I meant any computer connected twice. If this computer forwards the broadcast from one interface to the other that could lead to a forwarding loop. You could test this theory if you connect each computer only once and reenable the search LAN feature. If I am right your problem is not caused by btsync but by your network setup and just triggered by broadcast packages.

@Noel: BTSync sends broadcasts if you enable the "Search LAN" feature. I guess you have some kind of network loop. As this loop seams to be triggered by IP broadcast but not the usual ethernet broadcast (ARP), I guess you have one computer that acts as a bridge in this screnario. Do you by any chance have a computer that is connect via two interfaces, e.g. via two LAN ports or via WIFI and LAN at the same time?

@trumad It could of course. When a single directory entry has an error all child elements would be without father and depending on filesystem on OS would either be lost or moved to lost+found. Either way btsync would see that as files being deleted. But that is only a guess. If you never had any problems on your disks and you didn't reboot any node, it is more likely that btsync has a bug.

Hey trumad, have you checked for filesystem problems? If you had a filesystem error on one of you machines that could result in that directory being lost and btsync could then misdetect that as a delete operation and sync that to the other machines. If you have Linux you might want to do an fsck and look at the lost+found directories (though I doubt you will find it there as you got lots of free space). Also you could use foremost (http://wiki.ubuntuusers.de/foremost) on your block device to rescue the mp3 files (and maybe videos) if they have not been overwritten since. At least you have multiple chances per file, one for each synced machine.

Ok, I think it would be best to have some kind of repository (Github?) for the files then.

Hi, you should not move the users config files. Instead you could check for both locations and use the new one if it exists. Maybe you could even print a warning message if the file exists in the old location. Should I have a look at the restart-on-update functionality? BTW: Congratulations

Hi, thanks a lot for your packages, I know it is some work to be a package maintainer. Your packages run very well for me but I have some problems with the updates. Sometimes I wonder why one of my machines is not running btsync anymore and I discover that the agent has been stopped by an update, I guess you do a killall of some sort in the update script. It would be great if you could start btsync again after the update. I guess this is a problem as the btsync-user agent runs with user privileges but the update is a root process. You might be able to solve this by running the agent in an endless loop as long as there is a running state file. If there is an updating state file in a global location, the loop will sleep for some time and then check again. This way, your update script could just create this updating state file and kill all agents. Afterwards that state file could be removed and the agents will automatically start again the new version. If you want, I can send you a patch for this.

Idef1x is right. You create an empty directory where the files should go to and then you simply add the folder in the web-gui. The only difference from sharing a new folder to importing a shared folder is that you do not create a new secret but instead you enter the secret of the remote folder in that text field.

BTSync opens a webserver at localhost:8888. But if you have Kubuntu, why don't you just install https://launchpad.net/~tuxpoldo/+archive/btsync ?

Lets not get into the discussion of AES 128 vs. AES 256 again, both are secure enough. The main point of this solution is that the files are encrypted on disk nad not only over the network. Your point about shifted data is correct but I doubt TrueCrypt uses that a lot as it is a very uncommon operation that triggers worst-case behavior also in most of the filesystems. I am currently using encfs and synchronize the encrypted directory over btsync. That works well and I did not find any problems so far.

I experienced the same. I think it is because that link has a higher latency due to the tunnel and the token used for authnetication only has a very short lifespan.

To all of you that get parsing errors on lines with comments. Please try to put the comment on the next line or remove it completely. JSON normally does not allow comments at all and I suspect there are bugs in the code that parses the comments out of the config file. (If it was OpenSource I would invest a few minutes to write a proper parser...)

There simply is nothing you can do about that if you don't want to ask the user every time. If you store something on disk that lets you decrypt your files it also lets everyone else decrypt your files if they get hold of it. Maybe we should grab the password when the user logs in and use that to decrypt the secret from disk and store it in memory as long as the user is logged in. But that requires some pam magic and needs to be done by an installation routine, so I guess the developers do not feel responsible for that.

I think the implications of having different .SyncIgnore files are too hard to grasp. What does it even mean when a file is being ignored? - Are changes to that file ignored and not sent to other peers? - Are changes from other peers regarding that file ignored? Depending on the answers these questions that scenario could result in a one-way sync for some files or that the files are only synced by a subset of all peers. In all cases this is very hard to understand and even harder to debug as you can not see the .SyncIgnore files of other peers.

+1 That hit me too, I expected those files to be synced. I helped myself by symlinking to .SyncIgnore to some other file that then gets synced.

I would go with the more flexible aproach of rsync (man 1 rsync). In short they allow lines in the exclude file to start with "+ " or "- " (note the space behind). Lines with a plus are include rules and lines with a minus are exclude rules (as well as lines with neither plus or minus). The first rule that machtes counts, if none matches, there is an implicit "+ *" at the end.

Hi, I would like to participate in iOS and Android testing. Thanks

I just want to pull this thread up as no staff member has said anything to these ideas.

That works for me. What kind of errors are you getting? Your are not for chance trying to sync system folders or use ports below 1024?

Hi, I just installed BTSync on 3 computers running Linux and want to share my feedback. In general it works but the linux binary could be improved a lot: My first impression was that the binary did nothing. It did not print anything, it did not do anything. Apearently it started a daemon and returned without even printing a single line. So I propose the following: * The binary should display help when called without arguments * When the binary spawns the daemon, it should say so and maybe display the process id. Another thing that I found complicated was the web configuration. * The default config listenes 0.0.0.0 which should be changed to 127.0.0.1 for security reasons as only http is used. * The passwords should not be required in cleartext, instead password hashes should be supported (this should be enough to authenticate a user). Also I found the configuration very unintuitive. * The program should create the directory ~/.btsync and default to that instead of .sync in the folder of the binary. * The program should create a config file in ~/.btsync/config with sane defaults and use that if none is given * The program should be changeing the plain text config file instead of writing to some binary settings file. It is not very intuitive that settings are stored in two locations one of which is non human readable. As I said, the main functionality is just fine but imho these points have to be addressed before it can be used by average users. If this was open source I would likely have attached a patch...