benguild

I don't know what's wrong with 2.0.93, but: 1) It's showing hundreds of ghost peers. 2) It locks up on my Mac and pinwheels in the background. 3) It's overwriting files coming back from another peer with older versions! This is a huge problem! The betas were fine, the launch version seemed fine, but now I can't even use it. I think this is it for me, sorry guys.

Just updated to 2.0.93 (Mac) and have this issue with a test server that's running Linux. Honestly this software has gotten too complex for me and I'm kind of unsure on how to proceed. This seems like a beta glitch and I'm surprised that this version was released to the public. I've been using Sync for a while without issues like this. Any ideas? The program is locking up now as well...

Certificate based folders? That sounds interesting, but who is the certificate authority? How are user access changes propagated?

So if we have a couple of folders syncing between two computers with 2.0 installed, why do the folders still say 1.4 on them? I'm kind of confused as to what's happened with this "Pro" feature introduction... as I'm pretty sure that I don't need to upgrade for any reason but I'm afraid something will break after the 30 day trial. Can anyone clarify what is going on here? (P.S. I almost feel like I'm being penalized for being a beta tester now.)

Is there a solution to this? I tried ignoring it but it still shows up in the pending items.

Mac OS X Yosemite has "dark mode" and currently the BitTorrent Sync icon looks nearly just like a flat grey circle. Would be awesome to have an icon variant bundled to support that correctly.

I'm curious about these cloud solutions but not sure what's good. The problem I see is that BitTorrent Sync is pretty limited in adoption and understanding right now ... (not to mention beta and sometimes unstable) ... so I'm wondering how anyone can really sustain an operation's development needs and costs beyond it being a simple hobby. With that said, if it is someone's hobby, I wouldn't mind paying a dollar or two a month for a bit of storage to try out? Hmm

I don't understand what the different between the new sharing features are and the older key exchange. For example, I'd like to have to approve new machines to sync with mine ... and be able to revoke that approval later. Is this only on the new "sharing" system? Is this through a centralized server or authority? How does it work? (with Linux machines, etc.)

I agree that a solution like this would make sense

Nodes were only appearing duplicated over LAN, not WAN. Cannot reproduce when connecting via WAN and therefore the logs are unavailable.

For me it's still doing this... if I disconnect from Wi-Fi for even just 10 seconds when I reconnect it says it has to reupload entire folders and eventually cuts through the entire filesize to "synced" after like 20min... but in the process it's resending all of the small files that are too small for analysis vs. transfer. Seems wasteful. Dropbox syncs instantly

Screenshot attached. There are only 2 devices on these test folders. The rest are all duplicate devices that often appear instantly. From the logs I can see that the other clients are making like numerous inbound connections at once so I wonder if it's accepting multiple ones for the same folder at the same time?

It's doing this quite often so I'll try to capture it next time.

Very strange. I tried downgrading the other nodes to .105 but even with this, .106 still reports multiple nodes of the same machine/folder and with different statuses. OK weird, even after reverting to .105 on Mac it's still doing it. This has only been an issue since updating to .106 on all nodes and then trying to revert nodes one by one due to it.

I've noticed that if I have sync paused and then tether my iPhone it begins syncing automatically. This is not ideal. Worse, I have to go into the context menu and uncheck "pause" and recheck it to get it to pause again. It still thinks it's paused but goes into zombie sync mode or something

Right— However if the second key is of a variable length vs. the first being of a fixed length for simplicity and branding's sake... then that's different. Another way to treat this might be to treat the secondary key as a data encryption key ... where perhaps without it someone can connect to your "stream" just by having your secret, but won't be able to actually decode anything otherwise.

Brian— 105 is the best build I've tried so far. My recommendation for you is to backup your synced folders and then completely clear out ~/Application Support/BitTorrent Sync/ to reset your sync state. I've noticed that when a Linux instance crashes a few minutes after launching that this is the only way to fix it. (just a complete rekick)

I considered building a simple web script that spun up "btsync nodes" or whatever... but honestly in hosting the margins can be razor thin and with BitTorrent Sync in beta (and not always stable) it just seemed like it wasn't a good time or anything. plus to be honest all I'd pay personally is like $1-$1.50/mo for a small amount of storage of like essentials. I've got my eye out for something simple and managed but right now it seems like all there is are cheap VPSes that happen to bundle more disk space than another for the same price

ref: http://forum.bittorrent.com/topic/29854-if-you-restore-from-a-backup-would-sync-overwrite-the-newer-files-on-other-nodes-with-backed-up-copies-or-pull-newer-copies-from-other-nodes/

If it crashes you might need to dump the data directory and start over

If I move a bunch of small files out of a sync folder with a deep directory structure, a syncing ARM device (even if it's read only) will crash and the only way to get it to work again is to dump all of the data and reset the entire BitTorrent Sync setup. (essentially rm -rf the data folder with the settings.dat, etc. — and the sync folders themselves) it's kind of bizarre because downloading a fresh copy of everything works, but I've noticed consistently that it can't handle very deep directory structures or major changes. crashes after a bunch of "incorrect metadata" or "missing file" messages (sometimes with or sometimes without a "Received shutdown request via signal 2" at the end of the log), and then crashes during "loaded folder" in all subsequent reboots. EDIT: I just wanted to clarify that this consistently happens and it wasn't just a one-time thing. Running the latest .94 release

I like the idea of having a "two-factor" authentication system. Aside from having matching secrets, it'd be nice if the nodes could have a pre-shared key that also has to match or they won't talk to each other. The idea here is that outdated notes could be excluded from the secret without having to change the secret, and it also provides and additional level of security where the user can create an much longer secret key of mixed character sets. I think this would be a great advanced/hidden option for added security given that it would be basically impossible for someone to guess a secondary key, but it makes use of the existing 33 character secret system.

I actually just tested this as an experiment and found inconsistent behavior. If I went in and modified the files before they synced, that copy would sync over as expected to other peers. However, for some reason if I only modified rows in a database, that database was somehow overwritten later by data from a read-only node after restoring from a system static disk backup. It'd be nice if Sync would instead prompt for conflicts (with an option to "apply for all" or something to not receive a million prompts) vs. just overwriting local data. Date differences can be a little suspicious and data loss really sucks. Could someone re-title this thread and move it to the wish list forum?

Just wondering. I would assume it should pull newer copies from other nodes, but the files restored from backup were technically "written" more recently to disk. (although not updated)

Understood, but not for the new types of nodes. As I understand, the older key styles are only supported for legacy reasons.