• Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ChrisH

  1. 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. 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 on non-static connections.
  7. How would BTSync know that your disk starts failing? That's the operating system's job.
  8. How would BTSync know that your IP address is static?
  9. Pause synchronisation, remove the old folder from BTSync (be sure to copy the secret first), move the files to their new location, add the new folder with identical secret in BTSync, resume synchronisation.
  10. Did you read the thread completely? The feature is not "planned", it's already implemented - and pretty much in the way you describe.
  11. 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
  12. And how would it "check if system dat is correct"?
  13. 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.
  14. Seems like you don't know what an "intent" in Android is It's kind of an API call that can be triggered by external applications.
  15. Can you be more specific about the nuisances you encountered? In my experience there is no notable difference between real and symlinked files/folders.
  16. Can't you just use symlinks for that?
  17. There is no such option. Why would you want that? BTSync is a peer-to-peer platform, not the master-server-dumb-clients solution that some people seem to expect.
  18. Yeah, they removed to option for ad-hoc sharing from the mobile version some time ago. Don't know why.
  19. But in his situation and c) are still available on his thousands of subscribers. So all he really needs is a) the key.
  20. Monitoring a specific folder would be okay, I guess - but then what's different from just sharing that folder?
  21. 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.
  22. That title is not really written like feature request I agree. The receiving BTSync should look at the hash of the "new" file, say "wait a minute, I got that somewhere" and copy it locally. I'm guessing it can't move it right away because BTSync sees a move as deleting the old file and creating the new file - please correct me if I'm wrong.
  23. Unless they just reset their system date. Security is hard, people.
  24. Can A B C D E connect to each other using other methods like ping or a network share? Maybe this is a VPN/firewall problem. In OpenVPN for example you have to explicitly set the client-to-client option.