rdebath

I've seen your issue WRT the local lan connections, it has been raised with suggestions for fixes. Meantime I've made sure that only one node per site has public internet access for BTSync, the others only have lan access. Rsync style syncing has been raised multiple times, I suspect aligned chunks from the old file will be implemented shortly with full unaligned rsync style chunks as a maybe later. Your issue with multiple corrupted copies of the file hasn't been stated quite so well, I and others have seen problems with random files but nothing really repeatable. It may be good for you to turn on debug logging, but check with kos13 first as your log is likely to be really huge and they may have already found the issue or only need part of the logging to be turned on. Re the open source issue, don't worry about it. Consider this a proof of concept, even if it disappeared right now there would be a significant demand for "Just like this, but a little different". More than enough to prompt a competent open source author to start the job. In fact IMO, the application is simple and useful enough that it may happen even if BTSync just remains closed source. What's more the tracker and relay protocols only took a few minutes to decipher which lowers the barriers further even without a full protocol specification (which has been promised once it is stable).

This probably won't happen because it works in a completely different way to BTSync BTSync doesn't provide a fake filesystem, if BTSync stops or is even uninstalled the directory it was monitoring remains unchanged. BTSync is designed to be a simple reliable tool to do this simple (to state) job... "Make this directory have the same contents as every other directory in the world labelled with the same key." A fully distributed filesystem as you're requesting is a very different animal and many, many times more complex. The closest you're likely to get to this is to use a network filesystem to a local NAS device then install BTSync on the NASs to keep the remote copies intact. You use-case probably doesn't need a caching filesystem as you're doing a slow linear read of a large random chunk. This usage pattern will probably need to free up space in your cache before it ever gets reused. Note: The pattern "The Client connects to a local node for the distributed file system server" is also common for distributed filesystems because it helps reduce the complexity and improve the performance when the file servers guess wrongly about where to store the data. PS: Just to illustrate: I wouldn't be worried about making a clone of BTSync, given a reasonable motivation, But a distributed filesystem ... nope there has to be an easier way.

BTSync almost certainly uses the same DHT implementation as BitTorrent (Mainline_DHT) Current the only configuration is an off switch; and it appears that's not 100%. BTSync is peer to peer

NO, in non-technical terms, it is completely impossible. It's far more likely that you'll copy and paste your secret into this forum without noticing it. R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5

ifoo, sorry I skipped a couple of steps. Strictly speaking your issue isn't a BTSync one the problem is that a filename on ext3/4 can only be upto 255 bytes long; your filename is long enough that the extra extension the BTSync adds takes it to 258 characters. combine that with UTF-8 and the base64 encoding that encfs uses and you have very short filenames ... this is too long "ｦｧｨｩｪｫｬｭｮｯｱｲｳｴｵｶｷｸｹｺｻｼｽｾｿﾀﾁﾂﾃﾄﾅﾆﾇﾈﾉﾊﾋﾌﾍﾎﾏﾐﾑﾒﾓﾔﾕﾖﾗﾘﾙﾚﾛﾜﾝ" Add to that the fact that I really don't like the clutter that BTSync scatters around (eg the .!sync files) the obvious solution would be for BTSync to stop cluttering up the share with the *.!sync files and put them somewhere hidden, like a .Sync directory.

To need the _glibc23_ versions you need to go all the way back to Debian Etch (Mid 2007) or Debian Sarge (2005), but Woody (2002) is too early; it says "GLIBC_2.3.2 not found". BTW: The package you should be checking the version for is "libc6" or "libc6-i686". PS: Can I have a version that runs on a Woody ?

Just for the record, I agree! Any timestamp is a very poor way of deciding which file is the one to survive. They can all be manually set to anything you wish and so confuse the program. IMO the timestamps are only useful to help distinguish changed files, not to decide which is better. But your "Conflicting version from Node X" won't work. For stability within the network you need both nodes to make the same change to the filesystem. So in this case the timestamps can be used to decide which file keeps it's original name.

Kos, You need to use the created time of the file. On Windows it's easy; the filenodes have a created time. On Unix it's not so easy. (ctime is not the created time) You have to save a created time in your data. To initially find this time you use the last time you scanned (1/1/1970 for never scanned before) and the current time to decide the time range it may have been created over. If the modified time is in this range use it. If the modified time is before the range you should use the time of the start of the range. If the modified time is in the future you should obviously use "now". It would be nice if you could store the created time in some standard format in the extended attributes of a file (eg on ext4) I expect samba would be something it'd be good to be compatible with. What would be really nice is to take advantage of the fact that ext4 actually does have a file created time. NB: Just to be clear, the time you use as the "sync conflict resolution time" for this file is the later of the created and modified times that are before 'now'. edit: Oops on the NB

... slightly different configuration than normal... That doesn't mean "turned off" does it?

Okay kos13, that's it. I want to be able to store the partial files in the .Sync directory (eg: .Sync/partial/7a/b8dc8456c25f132551f157c77a1888ef918fac.part ) NB: While they're at it clean up the clutter; move everything into the .Sync directory ... .Sync/Ignore, .Sync/Trash .Sync/ID .Sync/settings.dat .Sync/config.dat .Sync/metacache.db etc etc.

The metacache is exactly what it's name suggests a cache. It's actually a cache of torrent files for each file in your share. If the file is needed and it doesn't exist it'll get regenerated; with a modern machine (and spinning disk) and a small file I would expect it to be faster to regenerate the file than it is to fetch the file from disk. If you have "too many" you can delete them. (I don't know if you should stop BTSync first though). I trust the next version will delete some of the files itself; especially in the case where the torrent file takes up as much disk space as the original file. This will be especially important if the data is moved to a sqlite DB as it'll be more difficult to purge old files manually.

Okay make sure it's the same as this, then you better work out if you need to raise a bug on the auto-update functionality. Did it fail or did you turn it off?

Okay, 20 days, not too bad: here and here ⟹ c&p pm Be careful out there!

Hmm, when you transported did you take the sync.dat file with you ? I assume not, therefor it reindexed and resync'd. Were all the files there and undamaged ?

Your patch will only work on 64bit windows as 32bit needs the upper half of the address space clear for the kernel to map itself into. Hopefully, nothing like this will be needed for the next version as it's memory requirements will be "much lower".

That's a normal, if rather lame, attack. They're much less likely to find something that way than by attacking properly.

BTSync ignores permissions. This means it honours the umask setting and the sgid bit on directories. Though there appears to be a problem with the execute bit on 'other'. Nevertheless, for what you want you just have to set BTSync's umask to 007 and set the group of the share to btsync and set the sgid bit on all the directories currently in the share. . . . Yes, there's a bug when it creates files. The open()/creat() call sets the modes to 664 or 774 instead of 666 and 777. This means umask doesn't work completely correctly.

They won't see any corruption on that file, I don't. Even the minor typo isn't obvious. # .SyncIgnore is a UTF-8 encoded .txt file that helps you specify single files, paths and rules # for ignoring during the synchronization job. It supports ‘?’ and ‘*‘ wildcard symbols. # The first phrase of the first line explains your problem. # Note that .SyncIgnore is applied only to the folder where it is contained and # will not work with the files that have already been synced. Though I agree, this comment is just wrong. I suppose they don't mean ‘folder’ they mean ‘share’.

You don't have to uninstall, if you want a clean slate just make a new profile. eg: firefox -no-remote -ProfileManager

That sound like an excellent test, and yes, that is how it should work. Please do take checksums (eg md5 hashs) of all the files, before and after, on both devices so you can tell us how it goes.

Sounds like you saved the certificate in the browser then the certificate was changed in the BTSync webgui. BUT the "serial number" has been hardcoded instead of being sequential or random. Hopefully this is BTSync's normal password and you just deleted the settings.dat file so now you have to delete the old certificate from your browser.

Um, nope, this config is completely silent (except for the occasional DNS lookup and a www connection to www.usyncapp.com), until poked by a host that knows where it is. { "device_name": "Ghost", "listening_port" : 8080, "storage_path" : "/home/btsync/syncstate", "check_for_updates" : false, "use_upnp" : false, "download_limit" : 0, "upload_limit" : 0 ,"lan_use_tcp" : false ,"shared_folders" :[{ "secret" : "IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII", // * required field "dir" : "/home/btsync/data", // * required field "use_relay_server" : false, "use_tracker" : false, "use_dht" : false, "search_lan" : false, "use_sync_trash" : false }] } Perhaps, there's a bug in that dht will work in exactly the same way; ie if you poke it it'll wake up? Do we need a global flag to disable DHT completely? BTW: The dns lookups are unnecessary (and so technically a bug) because it's not using the tracker or the relay.

It is possible to detect traffic types, but if BTSync's traffic is detected as bittorrent it's a false positive, they are rather different. OTOH, OpenVPN traffic is almost impossible to identify, best you can really do is "It's UDP and looks very random, if it's on port 1194 it must be OpenVPN". I suppose you now have two main problems, why does OpenVPN work and why does BTSync fail. As it is working, a "verb 1" log from the NAS end of the OpenVPN connection should give you the IP and port number that the connection seems to be coming from ("Peer Connection Initiated" line). The matching port numbers from the MAC end would also be needed to see if the firewall thinks it's a NAT despite the public IPs. (Your faked DNS names are still fine for the IPs) If OpenVPN isn't on it's default port does it still work? If not someone has specifically opened the port and you're probably SOL unless you find a nice IT person. Then we have what are the differences between the OpenVPN's use of UDP and BTSync. You have OpenVPN in tls-server mode, this means that the NAS never sends a packet before the MAC. Turning off all peer discovery methods on the NAS would make BTSync act in the same way. You would have to add the NAS as a known peer to the MAC config. The other thing is MTU (packet sizes), I'm not sure exactly what OpenVPN does by default, but as the firewall is blocking ICMP it's probably breaking MTU negotiation. However, this shouldn't stop the initial BTSync "pings". Other than that, BTSync and OpenVPN traffic shouldn't be distinguishable. They're both heavily encrypted streams of UDP packets. Actually, that's not 100% true; it is possible to identify a TLS OpenVPN connection based on a signature for the TLS authentication unless you use the "tls-auth" option, then it's truly random, and a tiny bit more secure. Re; Port 123 on the NAS. Do you have NTPd running on the NAS? If so it'll already be using that port, plus BTSync will have to run as root to use port 123.

There are, btw, plenty of tools to "socksify" any client program. Example: dante-client uses a shared library hack, "redsocks" uses a NAT hack to catch the connections. These are Linux reimplementations of the Windows tools. Of course this doesn't help in the slightest with Tor. Socks5 will redirect UDP sessions happily, but as they stay as UDP Tor can't cope with them. Best bet would probably be to use either udptunnel for a known peer or OpenVPN with a TCP transport to relocate your apparent exit point to the OpenVPN server.

BTSync does not use compression. IMO, as it uses encryption it should have the ability to use compression (it stops any later compression happening) but it must be applied carefully as it's an expensive operation and likely to be unnecessary with the large files that BTSync has a preference for. The encryption can already cause a significant limit on the top speed without adding the cost of compressing too.