tsftd

Members
  • Content Count

    8
  • Joined

  • Last visited

About tsftd

  • Rank
    New User
  1. That's totally my bad, don't know how I missed it. Either that, or the devs have time machines.
  2. FYI you can either compile it manually (as with any other "unsupported" linux flavor) or install a package manager (such as portage) and install it from there. DDWRT does have its own built-in package manager, ipkg, which someone could make a package for, to simplify things. However, be aware that BTSync, much like torrent clients, may overload or run slowly on your router.
  3. I am in the process of setting up mutual backup syncs for my family. Having been through a major natural disaster in the past, I'm sensitive to the possibility of not only a hard drive dying (solved by local backup), but the entire location (house/office/etc) being destroyed (earthquake, hurricane, fire, etc). Bittorrent Sync fulfills this task admirably -- each family member/group (myself, my parents, and my sister) will have an old computer running Linux with a multi-terabyte drive. Each person will have their own one-way sync, which is tied to the other 2 computers. It allows each group to have 2 backups in different states (and countries, in fact), at minimal cost or bother (basically the cost of the drive, as we have plenty of old computers laying around, and once setup, there is practically no need for maintenance). HOWEVER, there is one problem. Each group has certain data that they don't want everyone else to be able to see. I have work-sensitive data (such as clients' personal info), my parents have financial records (their own and mine as they have DPOAs to manage certain financial interests of mine in the states since I live outside the country and in a very different timezone), and my sister's husband is (understandably) hesitant to have his family's sensitive information available on 2 other computers. The solution to this, of course, would be a "blind" sync. One which allows you to store the data on the synced computers, without that data being available to them. Simply encrypt the remote data (data in the "blind sync" location), while leaving the local data unencrypted. This would allow people to use the "cloud" feature without having to worry about the security of their data on the remote end. Ideally, there would be another option to have the "master" node encrypted but sync it unencrypted (for use cases where, for example, the data is stored "in the cloud" on a server node within a remote datacenter not under the direct control of the user, but synced nodes must be unencrypted for use). This would allow: Master node - Slave node(s) unencrypted - unencrypted (currently the only possible setup) unencrypted - encrypted (for backups without the backups being readable locally) encrypted - unencrypted (for cloud use without the cloud node being readable locally) encrypted - encrypted (arguably not needed, as local disc encryption and then syncing the encrypted data would accomplish the same thing under the current program)
  4. Yes, that's exactly the point of this request. It's to have a share type which DOESN'T do that. Call it "Archive" mode, or "Grab" mode, or whatever clever name the devs come up with. The point is to have a sync mode which will create any new files on synced nodes, but not sync any deletions. If you read the last paragraph of my post, I specifically point out that this is not currently possible. "One-way syncing (read-only) as currently implemented in BTSync fulfills all but the last requirement (I can delete on the home PC without affecting the server, but removing a file on the server will delete it on my home PC)."
  5. Maybe I'm wrong but from what I understand Sync gets a notification from the OS when a file is written to (either a new file or an update to an old one). If this is the case, and you're syncing your photos folder, listening for the action wouldn't help, as either way it should be instant. Remember, the "10 minute" setting is just a backup -- it should sync more or less immediately. It's possible that as chromaniac is suggesting, there may be battery saving features at play here that introduce a delay, but if that's the case then they would affect listening for android.hardware.action just as much. Maybe a sort of "latency" option to allow the user to adjust battery-savings vs latency would be in order if this is the case though?
  6. You should be able to, new Android you can't write to full SD card but you can read it all just fine.
  7. Using Bittorrent Sync 1.3.109 on both computers, Gentoo Linux and Windows 8. Also using 1.3.21 on Android phone. When transferring from Windows source to Android destination (via LAN), multiple connections are sustained even for large files and maximum practical bandwidth is saturated. When transferring from Gentoo source to Windows destination (NOT via LAN), a single connection with very low speed is created for large files (though multiple connections are used for small files). This is due to the nature of my ISP, which caps speeds per-connection. Using BTSync, I am pulling 200-400 kB/s while using multi-threaded FTP, I can nearly max out the theoretical 12mB/s. Likewise, making multiple sync folders instead of a single one higher in the tree (syncing subfolders independently) allows multiple connections (one per folder) which can speed up the process, but at the cost of usability. Per-connection capping is a VERY common practice for ISPs, so the ability to make multiple connections is very desirable.
  8. Yet another person who signed up just to request this. This is a MUST for anyone to use BTSync as I intend to: Set up a remote server which is automated to download things via bittorrent (say, a podcast). Use BTSync to sync those things which were downloaded to my home PC. Have the freedom to delete said things from the server or home PC as desired, without one affecting the other. Traditional FTP Sync software can fulfill these requirements, except that it doesn't work with bittorrent downloads (since it doesn't hash the files). One-way syncing (read-only) as currently implemented in BTSync fulfills all but the last requirement (I can delete on the home PC without affecting the server, but removing a file on the server will delete it on my home PC). As it stands, I have to either listen to the podcast before removing it from the server, OR manually move/copy it to a non-synced directory. At which point, really, I may as well just FTP on-demand as I've always done it.