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.