benguild

Members
  • Posts

    42
  • Joined

  • Last visited

Posts posted by benguild

  1. 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...

  2. @arguser

    Thanks for sharing the link

     

    @benguild

    Sync 2.0 supports boths new 2.0 folders and classic 1.4 folders, so when you upgrade your Sync it will leave existing folders as is.

    If we compare 2.0 and 1.4 folder briefly, we'll get:

    2.0 folders are:

    - certificate-based (you can't copy key and should always use link, also more secure than key)

    - support user access change

    1.4 folders are:

    - key-based (you can copy and distribute key or link)

    - do not support user access change or on-demand sync.

     

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

  3. 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.)

  4. 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 :)

  5. 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.)

  6. Exactly. Here's a UI idea: when you add a secret, offer an "Advanced" button. Pressing it would offer these choices:

    (•) Merge this device with other devices

         Any files that exist only on this device, or only on other devices, will be copied to all devices

         The latest version of every file will be kept on all devices

    ( ) This device has the master copy of this folder

         Any files that don't exist on this folder will be deleted on all other devices

         Any newer files on other devices will be discarded

    ( ) This device has only out-of-date files

         Any files that only exist on this computer will be deleted

         Any newer versions of files on this computer will be discarded

    I think the biggest difficulty here is not in UI, but in deciding how exactly it should work. If you choose that this one is the master device, when does that status end? Or, in the words of johnmarshall4, when exactly does it change from one-way to two-way?

    I would also find a fourth option useful, one that doesn't sync files that only exist on this or on the other devices, or differ in version, until the user chooses how to resolve the conflict. But the above three would already be a huge help.

    Until then, I sync folders using Beyond Compare, and only then feel confident to run BTSync on them.

     

    I agree that a solution like this would make sense

  7. @Devonavar

     

    In certain cases BTSync was re-indexing files all the time. It has not relation to the syncing xattrs between MacOS and Linux. The xattrs issue is going to be fixed in upcoming major release 1.4. Please do not revert your exceptions in ignore list for now.

     

    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

  8. Totally agree!

     

    I think it's basically about the perception (or rather misconception!) that people "feel" more secure if they are asked to provide two pieces of information instead of one!

     

    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.

  9.  

    It's still crashing a lot for me.. doesn't generally stay open for more than a minute before it crashes unless I pause syncing after opening.

     

    I'm happy to grant access to the share that I believe may be causing this problem if it helps with debugging.

     

    OS X Crash log attached

     

    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)

  10. 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

  11. 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/

     

     

    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)

     

     

     

     

    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?

     
  12. 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

  13. 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.

     

     

  14. 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?

  15. The secret length CAN be changed! See this thread.

     

    Also, there are already a wealth of other topics dealing with the exact same issue regarding security of secrets - some examples: (1 | 2 | 3 | 4 | 5 | 6 | 7)

     

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