• Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ChrisH

  1. Also BTSync does a lot of unnecessary overhead stuff for your use case, because it works on the principle that bandwidth is much more "expensive" than CPU time. Stay with your custom app.
  2. Sorry, but being a web developer myself I can tell you for a fact that nothing that uses Internet Explorer 9 as a basis can ever be highly portable. Not even to other IE versions. I repeat myself, but I would have gone all the way and used a real web interface. If opening a browser is too much for the average BTSync user then surely a client app with an embedded BrowserView would have been feasible.
  3. Try entering the path (e.g. /storage/scdard1) manually instead of browsing there.
  4. That's in fact the only (reliable) way, isn't it?
  5. Okay, as soon as someone announces officially that this is an Enterprise-only feature (I know this has not happened yet), I'm out of here. I hope it's not only developers who read this thread, but also the Product Manager(s).
  6. Yes, still on 1.3 (~ 10 machines). Evaluating SyncThing at the moment. Can't you do a real poll with numbers in this forum? I think in this way you'll only get responses from the people who don't like 1.4...
  7. If they had time machines, they would only work with IE9.
  8. I don't see what this has to do with IE9. Yes, it won't run on machines without IE9 (actually it will now), but for me portable was "does not have to be installed and can be run from any directory".
  9. Yeah, they broke that. See
  10. Can't you do this with the API?
  11. That's the classic conflict between comfort and security Maybe you could use a launcher where you can set passcodes for single apps? That way you would not have to wait for this request to be implemented. Thanks for the explanation. And no, I don't care what you sync.
  12. I'm not saying it's a bad idea or not possible somehow - I'm just saying that this requires some fairly major changes in both client and protocol, so I would not hold my breath for a prompt realisation.
  13. You could do this today by having a general "download share" with the "master" secret (of which you only give out the readonly secret to your members) and several "upload" shares, one for each contributor. With some background job you would then either copy the uploaded files to the download share or create symlinks - this could probably be triggered by BTSync API, so it would be near-instant. Pro: Works now, no change to BTSync required Con: You cannot use the Contributors' bandwidth for downloading to the members at once. The initial seed would all need to be done by your bandwidth alone (until at least one member has enough data to seed). This could be mitigated by having the contributors sync the "download" share as well. Also your "upload" server would be a SPOF at least for sharing new content. I think this subfolder-sub-secret stuff is a nice idea, but the changes required to not only the BTSync client but also the protocol are somewhat prohibitive.
  14. Okay. So would you care to elaborate what use you are seeing?
  15. I use symlinks to "merge" subfolders into shares. I want my peers to sync the files, not the links. Also, I don't want BTSync to arbitrarily create folders all over my drives. Edit: Sorry, I overlooked the "if in the same share" part. With that, I have no objections.
  16. What is it with people wanting additional passcodes in every single app they install? If you don't want someone else to see your porn, lock your phone and don't give it to them unlocked (or watch what they are doing with it).
  17. I have not tested this, but BTSync is supposed to handle removable drives now. In earlier versions it would indeed interpret an unavailable folder as "all files have been deleted" and merrily sync that deletion to the other nodes.
  18. Yes, you can set up many different folders with separate secrets and only the devices that have the secret to the folder can sync it. They will disappear from your PC (but moved into an Archive folder - BTSync can be configured so it will never clean that archive folder up). It does not always sync both ways, you can have readonly secrets that only receive files and changes, but never send them. Which won't help with the phone scenario.
  19. Huh. I have no idea what I was thinking when I wrote that. I can only guess I mixed up threads and thought you posted in the "BTSync as a Windows service" thread. Sorry for the confusion.
  20. Well, it's always easy to blame the user (I'm a product manager myself - I know). But I would certainly say you don't exactly advertise the fact anymore. It's not mentioned in the (official) FAQ, it's not mentioned anywhere on the product page, it's not mentioned in the 1.4 blog post ( and like I said it's not even mentioned in the app itself. And if the new 1.4 UI is as easy-to-use as you claim in the aforementioned blog post, frankly the average user should not have to read the docs in the first place ;-) So yes, I should you should make it more clear. A simple "beta" after the version number on the download pages and in the app itself should be enough.
  21. I'm just saying that as a normal user that just goes to the website, downloads the app and installs it, you never read "beta" anywhere. I'm sure it's mentioned somewhere in the documentation and blogs and whatnot, but nowhere prominent. It doesn't even say beta anywhere in the app itself. So I still think it's unfair to expect the average user to know he is using an unstable beta product. Bittorrent can't have it both ways. Either they make it very clear it's a beta product and then it's okay to use that as an argument if there are changes and errors, or they don't and it isn't.
  22. The funny thing is that this beta status GreatMarko insists on is not mentioned anywhere at all on the official web site: Everything there and during setup gives you the impression of a finished product. I don't think it's fair to hide behind the "beta" status if the user is not alerted to it anywhere.
  23. Yes, but that uses only the central BTSync relay server(s) which are easy to block. The problem with ortreums idea is that you need one node that is known to the client in order to find any relay nodes at all. If that one node is not a central server, you'll have to configure it by hand or scan the network at random or use some kind of multicast, all of which methods have their specific drawbacks.
  24. That's not going to work. You might make your home PC a read-only node, so deleting files there won't affect the server, but deleting files on the server WILL move them to .SyncArchive on your PC. Edit: Disregard the above - I was probably thinking of the wrong thread.