joebush

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    3

About joebush

  • Rank
    Advanced Member
  1. The devs don't have any authorization to release any information about the protocol behind this product. It's fully up to the company to make that decision. This product is also still experimental. The client as well as the protocol are still being developed, so it would make no sense to release any information. I'm all for full disclosure of the protocol, and preferably open sourcing the client as well. And after this project is launched as a consumer product, I will be equally disappointed if this isn't done. But until it's ready, all we can do is test the software.
  2. This is currently not possible from within Sync. The only suggestion I can make is setting up a cron job on the server that moves the files (that don't end in !sync) to a permanent home.
  3. If you mean using Android's sharing functionality directly from BTSync, that might be more natural by using a context menu from the local file listing.
  4. I'm running 1.1.42 on PC and 1.1.23 on phones. But this has been working without issue until today. That's why I'm wondering if this is a general issue. Can't believe the phone company suddenly managed to block access to trackers and relays. EDIT: Suddenly started working again...from both phones.
  5. Up until today my home PC (behind a double NAT) was able to connect with my phones (on mobile network with 10.x.x.x (internal) address). BTSync on the PC listed the phones with a cloud icon. Today, my phones and home machine are unable to connect. I haven't changed any settings and haven't installed different versions. I've verified the sync settings has tracker and relay turned on. I've even restarted BTSync. Are the trackers and relays still working? Any idea what else could be the cause of this? It was previously working perfectly.
  6. Yeah, you'll have to split it up, or at least group them together as best you can. It would be nice if a dev can tell us if it's a bug or intentional though, and whether they're considering changing it as I described. The way it works now doesn't seem to be logical.
  7. You should take the 30 seconds needed to try it before continuing to ask. You'll see it doesn't work.
  8. 1. Yes 2. Not possible. Turning off autosync is entered in the wishlist thread. 3. Not a question.
  9. It wouldn't be much of a backup if the backed up files could be deleted when a mistake is made on the source. I suggested over that they could separate Read-only syncs from Backup syncs. This could be one of the differences. Or possibly just have it be a per sync 'Allow remote removal' option on the receiving peers.
  10. For some reason, the .SyncIgnore seems to be the basis for which files a peer will ignore when 'sending' files, but .SyncIgnore doesn't seem to affect what the peer receives. Not sure if this is a bug or intentional. I don't like it either. I think it would be more natural if it ignored for all BTSync functionality.
  11. On my Win7 box, Truecrypt refuses to modify the datetime on the container file. The preserve setting is unchecked. EDIT: It suddenly started updating the datetime, so BTSync is syncing changes now.
  12. Try syncing a directory below \\Fads1a58cc (like \\Fads1a58cc\mysync). I haven't had a chance to try it myself, but it occurred to me that there could be an issue syncing a pathless unc.
  13. Or you can just name it something valid so it syncs, and rename the synced version to .SyncIgnore afterwards. Too much trouble to email files.
  14. Apparently, it only seems to affect outgoing syncs from the peer with the .SyncIgnore file. It will still request files from other peers even though they fit .SyncIgnore. I would have assumed it would ignore any local and remote files that fit with .SyncIgnore. I.e. that it would ignore all files fitting .SyncIgnore for any BTSync functions, whether incoming or outgoing transfers. Maybe it's a bug. GreatMarko wrote in another thread that .SyncIgnore should be the same on all peers. But I think he means for the sake of being consistent. If they truly needed to be the identical, Sync would do it itself. Hopefully, BT is investigating what the smartest solution is here.