ChrisH

Members
  • Posts

    247
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by ChrisH

  1. The idea is not strict security, but to have more awareness on new devices joining a share.

     

    As long as that proviso is understood and made clear to the user: +1 from me. I also think your idea of an .syncDevices file should work.

    I just would like to see something better than the easy-to-guess device name for that identification purpose, at least internally. Maybe the already existing .SyncID printed as base64?

  2. -1

     

    With the current behavior I can just plonk BTSync.exe into whatever directory it's installed in. With your suggested change I would have to manually delete the old version and rename the exe back to BTSync.exe every time.

    Also, every web link would have to be updated every time there was a new version, instead of pointing to the newest version automatically. (This could be worked around by creating a /newest link that internally redirects to the current exe.)

  3. So what happens if the user on one device clicks "yes" and another clicks "no"?

     

    As I have said many times now, the problem with requests like that is that BTSync's design treats all R/W nodes as equal. There is no master node that could control things like device access, secret renewal etc.

    This needs to be solved first before any ideas about a node approval process can be considered.

  4. Well yes, you can determine whether your computer has it's address assigned statically or via DHCP. But the interesting point is whether your public IP (i.e. the one of the router your computer probably is behind) is static or not. And there even static IPs (in the sense that they don't change on every connection) are commonly assigned via DHCP.

     

    My home PC has a static IP, but my internet connection does not.

     

    My work PC has an IP assigned dynamically via DHCP, but our internet connection there has a static IP.

     

    It's just not that simple.

  5. I can not agree with ChrisH. All hashes are already there, there is no need to compute another ones.

     

    You misunderstood me. I am not against a feature like that if it concerns moving files around inside an already shared folder. In fact I would very much like to have that.

     

    smg2006 suggested calculating and keeping current hashes of ALL files on his computer, regardless if in a synced folder or not. That's all I was arguing about.

  6. So I would need to enter the server's own (external) IP into the list of predefined hosts on the server itself? Not really intuitive. Has anyone tried what BTSync does then? Does it actually try to sync with itself?

     

    But +1 for the general idea. Maybe with a hostname instead of an IP so it works with DynDNS et.al. on non-static connections.

  7. Yeah, I got you the first time - all three components must exist in order to recover the files. But b ) and c ) are available on the thousands of Enc-RO peers. So all he "needs" (i.e. must keep in a safe place for himself) under that premise is the key.

     

    If all subscribers die and/or the Internet collapses before he can get to his safe copy of the key, he's out of luck. But then we'll have more pressing problems ;)

  8. I now it. I want to exit automatically - from automateIt or Liama...

     I wasn't talking to you.

     

    But +1 from me for the feature. Seems that currently Llama can't kill BTSync even with root rights and the "die die die" hardcore option.

  9. I would go as far as to say, if the file created on machine A already exist on machine B but not in a shared folder, then transmission should be avoided. 

     

    Do you really want BTSync to hash every single file on your computer on every single file change just on the off chance that you might move one to a synced folder? I don't. The CPU and IO wasted on that would be FAR greater than the time it takes to transmit the small percentage of files that really get synced some day.