![]() I could also prevent that particular sync node from being allowed/able to make any changes to the files without me noticing. This way, if I want to store my private files on a fast server in a datacenter to access them from anywhere, I could do this with syncthing without essentially giving up ownership of those files. What I propose is somehow configuring nodes which are only sent the files in an encrypted format, with all file contents (and potentially file/directory names as well or even permissions) being encrypted. One way to do this is using ecryptfs or encfs, but this has many obvious downsides: it is not an interoperable solution (only works on Linux), the files are actually stored in encrypted form on the disk (even if the resource is trusted and this is not necessary, for instance because of the file system being encrypted already), etc. ![]() not exactly doable with close source software.ĮDIT: Just to point this one out as well: With Syncthing you don't have to use their "Announce" server (the equivalent to the relay/tracker of BTSync, to put it very simply) it you already wear a tinfoil hat, you can setup your own server and make Syncthing use that one instead though your own server has to be reachable from the internet if you want to use it with other peers outside your LAN (read: either leased server of your own machine in a DMZ).So I have had a look at BitTorrent sync, syncthing and alternatives and what I always wondered about was the possibility to not only sync between resources I own and trust, but also external resources/servers which I do NOT trust with my data, up to a certain extent. "absolutely unfavorable UI revamp" or other "pushing certain dependencies upon users just because"). since Syncthing is Open Source one can always fork it (am currently trying to get cozy with "Go") and iron out "betterfications" if said "betterfications" happen to go down south (i.e. I'm also in the progress to code up a systray indicator (I know about Syncthing-Tray for Windows, but that one's outright c**p) to act much like the Dropbox one (just the most important notifications and not spamming each-and-every event to the screen like Syncthing-Tray does). It's consistent across platforms, loads up incredibly fast (much unlike a certain 1.4 UI) and is well structured (the BTSync devs could take that as an example about "How to do things absolutely right"). Lastly, I run Syncthing as a service (via the NSSM "How To" method) and am very pleased with the browser UI. I actually have only one system still running BTSync (1.3.109) - once "resume sync" is confirmed to work this last instance will fly off and be replaced with Syncthing as well I don't want to make my friends switch before this last "showstopper" is resolved - it's a pain in the rear when a large folder starts re-syncing from scratch because it was interrupted before it finished up. I once tried the same with BTSync (back in the 1.2 days) and it wasn't too breathtaking as well (~7MB/s avg. synchronizing a test folder consisting out of 8GB of random small files (100K files, 4KB min, 20MB max, randomly generated with a script to mimic a mixture of image and mp3 files in terms of file sizes) runs at rather consistent 31MB/s average where copying via Windows (via SMB) results in <4MB/s averaged. With a ton of small files Syncthing still fares well better than Windows' SMB. Linux CD/DVD ISOs) files (Windows via SMB tops out at ~110/115MB/s here). While it doesn't max the Gigabit link, I see up to 60/75MB/s when syncing a couple of large (i.e. ![]() within my LAN the speeds are far above BTSync. There was only one version in the 0.9.xx series where sync totally broke, but that was fixed within a few days at the next release version (I guess it's worth pointing out that Pulse/Syncthing gets at least one update a week - they don't take 3+ weeks to fix up small-fry problems like a non-working "listening port value"). ![]() I was actually testing Syncthing for quite a while now (between a variety of VMs and a variety of ARM devices), starting with 0.8.xx, and didn't have much of a problem with it - other than it being unable to resume interrupted syncs (not sure if "resume sync" has been already implemented in 0.10.3 or if it's still work in progress - haven't checked the changelogs / git commit in quite a while).įor me it's working rather perfectly, though you well better expect "breakage" to happen for as long as there's a "0" as the leading major version number. "Not very stable"? That's not exactly my experience.
0 Comments
Leave a Reply. |