fragtion

Is there any consensus yet surrounding this problem? I've tried v1.4.103 and it did not solve my problem with 1xRW to 1xRO peer going into indefinite "Out of Sync" in v1.4.111, even with "overwrite changes" ticked on the RO replica... will it work if I delete and re-create the sync definition for those folders under v1.4.103? Or does the 'experimental' build actually resolve this problem? I would like to try it too - where can we download it?

Well if the data is already synced, then BTsync will only re-index it and compare those indexes with the peer. Only any changed contents will be transferred. So this should not result in a large amount of traffic or time spent to ensure that the replicas are consistent Since 2.0 I've personally been trying alternative software out, because I fear that v1.4.111 of BTSync might have too many bugs (which they most likely won't address for v1.4 anymore) so it seems to make more sense to switch over to a more active project where our minds can be at ease that any discovered bugs will actually be attempted to be fixed. It is now reassuring however, to hear that you are using v1.4.111 on a 7TB replica with such success. Are all your peers in read+write mode? I found that when I use a "read-only" peer in v1.4.111, the syncing just stops working at some point and the peers stay out of sync, which is unfortunate as the read-only method could work great for simple backup schemes. So the read-only feature is basically useless unless we upgrade to 2.0, which in my case will not happen.. so...

It really seems to me that the implementation of bloatware and subscription fees became a much higher priority for the developers than the implementation of actually needed/useful features such as this, which would have gradually allowed BTSync to become the very state-of-the-art, widely used/'go-to' tool for simple, flawless and efficient cross-platform syncing capability that is optionally gui-enabled - effectively a bi-directional (multi-peer actually), fully automated/hands-free rsync on steriods - at least that was the very promising experience I had when first trying this software out at v1.3, and indeed it seemed to be well on track to realizing this great goal But their new approach since Sync 2.0 has defeated this objective: BTSync is no longer a lightweight, free utility - there's no real use caring if they even implement this anymore. It's not so simple to deploy, or use anymore (even after you've dealt with the bloat/nagware) - so yes, let us rather keep the suggestions to ourselves and allow the paying customers to instead provide feedback, because the developers clearly won't allow us to reap the benefits of our suggestions anyways, plus the subscribers' ideas/requests will obviously be given higher priority. If this feature does ever get implemented, it will probably be on a 'subscription extra' based model, meaning that you will have to foot an additional monthly subscription to unlock such capabilities. Sounds crazy I know - but how far fetched is it really, in light of what they have already done? The truth is, we have no guarantee anymore so more handicaps such as this, on the free version, become an increasingly more plausible reality I know I am being spiteful, but I simply cannot otherwise fathom/express my infuriating frustration over the fact that this project made such a radical 180 turn on us, especially in principle, given the fact that they EXPLICITLY promised to keep it free for life. For this reason, I can't wait for the open source alternatives to evolve further (just a matter of months now) so that the notion of paying a monthly subscription fee for a decentralised p2p sync tool becomes increasingly more obviously absurd!

Moving to Syncthing and will deal with it's quirks until they undo this subscription bs in BTsync 2.0 and all the bloat, big mistakes imo

Many thanks for your response RomanZ. It's good to hear that you guys are going to consider the "Restrict only to these peers" feature idea, which would certainly be great if implemented. Unless I misinterpreted you, then I'm also really glad to hear that it's possible to simulate the desired behaviour in the meanwhile by making sure that all the peers simply have the extraneous search options unchecked besides for the predefined hosts. Will give that a try so long and see how it goes

Sure the 'newer' files weren't moved to the .SyncArchive ?

I understand that this project is still in beta phase, but there are a few obvious quirks which should be fixed asap, and I think this is one of them: I have a share where I have explicitly checked only "Use predefined hosts" in the preferences for that share (no DHT, no tracker, no relay, and no LAN search). I specified the desired hosts to sync with, however under the "Devices" tab, that share is showing all peers using that share key (including those which are not part of the explicitly defined list) - such behaviour continues even after restarting the app on all nodes. This can become problematic if you wish to have a central dedicated server/s and a number of lower-speed clients, and you wish for each of the clients to sync through the dedicated server/s only - but instead they seem to sync with each other as well (or is that just a status report?) which can saturate their respective upstream bandwidth Is there no way to restrict a share configuration to predefined hosts only on a client-by-client basis? This will allow greater control as expected. Right now the "Use predefined hosts" can be deceptive/counter-intuitive if it's still going to connect to the other peers as well. At the very least there should be another checkbox next to that one saying "Restrict to these peers only" ? I assumed such functionality by default, which does not seem to be the case after all. This could greatly enhance security as well, as no alien peers can connect to such a configuration which only accepts the predefined hosts I guess right now the "Use predefined hosts" feature functions more as a "Peer-finder helper" than an "access list"... if so, how could we define a strict access list for a given share, and shouldn't that functionality discrepancy be more clearly defined? It seems I am not the only one who has misinterpreted the behavior of this feature - I've found some articles via Google which review this software, where the authors also misjudged the "Use predefined hosts" feature as being a security enhancer, assuming that it excludes non-defined hosts by default, which clearly it does not. Am I maybe just missing something here?...

bumpety bump

I'm quite baffled by the fact that the Web UI is completely disabled without any option to choose otherwise when specifying the shared_folders in a config file. How are we supposed to monitor the precise details about each folder's indexing, sync, traffic, and connected peers status? The logs are very vague on this and mostly just report errors I can understand that web configuration would be disabled as a safety feature to prevent conflicts with the config file, but it should at the very least rather just switch to a read-only means for monitoring the daemon unless a command-line argument to see such status is available. If we want to disable the web interface, we can remove the configuration directive, but if it's purposely kept in there yet completely ignored by the app for seemingly no reason, then that should be considered a bug/problem if anything I can't seem to find any other way of doing this right now without enabling the web-based configuration again, which of course I have done So unless the web-UI is in fact a recent development which will ultimately phase out the config definitions, then some kind of status monitoring for config-defined shares should be quite an urgent priority to resolve, surely? I initially switched to the config file hoping for more control as I usually prefer working with configs, but it seems the opposite effect was achieved and I had to revert