• Content Count

  • Joined

  • Last visited

  • Days Won


About capi

  • Rank
    Advanced Member
  1. That's a huge improvement for the link sharing feature. Kudos for making it work so fast!
  2. Yes, but this is besides the point: with the secret, any new peer can join the network without prior approval from any existing peer. The approval process only kicks in when using the new Link feature.
  3. From my understanding it is this way: The certificate and approval only kick in when you use the new link sharing feature, which replaces the old "one-time secrets". It is only used to secure the exchange of the main secret. Once the secret is shared, there is no more approval of the peers required. This is based on the fact, that if you enter a secret directly, no approval is required. So I assume, that only one peer needs to approve and once the secret has been exchanged the peer will communicate with all the other peers without further approval.
  4. You'll most likely use a Linux version of btsync in a Docker container...
  5. I hope this means what it implies it means Looking forward to this "official info" very much Thanks for your hard work! And basically you confirmed what I tried to write in my answer. No data leakage but some potential troubles with the tracker / relay, but as you said, there are other means of peer discovery.
  6. Will those prefs be set to new files in the directory as well, or only to existing files?
  7. I just posted the following discussion to this blog entry, and I think it is also a valid repsonse here, but I am really looking forward to some official answer: The question is, how far this really leads to exposure of data. The claim is, that tracker and relay only ever see encrypted content (hash of secrets for the tracker, encrypted data for the relay). So if this claim is true (and this can neither be verified nor rejected based on the information here), the attack scenario is, that someone could do a DoS on sync, i.e. prevent peer discovery via tracker to fail by forcing an invalid tra
  8. At the moment, there is no background service, the application is only running when you see the notification icon is shown in the notification area. And I like it that way
  9. The i386 version of 1.3.77 crashes on my computer. Please see the attached log file. What I noticed is that the name of the folders is truncated, the paths are longer and similar names work on x64 hosts. For now I reverted back to 1.2.92 on the i386 machine, keeping all others on 1.3.77. Will this cause problems? log.txt
  10. There are some UPnP implementations that are buggy. You can also disable UPnP in btsync, should fix the issue also.
  11. @Herold Feit: this seems a weak counter-point because in case of very rare changes on a disk, the power saved and the noise reduction can be worth the additional wear of the disk drive itself. I agree with lolcat that there should be no need for re-indexing on read-only secrets as changes are not going to be sent anywhere anyways.
  12. RomanZ, you lose data, if no checkpoint occured, as data has then not yet been written back to database. If you delete it during checkpointing or the PC/app crashed while performing a checkpoint, you still need the WAL to recover/repair the data file. So no, it is not safe to remove the WAL file ever, unless sqlite removes it itself (which it does, when the last connection to the database is closed, as you mentioned). If the file still exists, the shutdown was not clean and the WAL will be required on next connection to the database. It is a temporary file in the sense that it will be remo
  13. It depends on how an application closes the DB connection, e.g. if it resets to REDO-log mode, it will remove the WAL files, for instance. But still, removing an existing WAL file will cause corruption, as they are part of the DB.
  14. Hi, if you have WAL-mode enabled for SQLite and delete the WAL file, you'll corrupt the database file. DON'T DELETE IT! (This is not specific to btsync, but to any app using sqlite with WAL enabled.) Additonal information and how one could deal with it is available from and other ressources on Best regards, Capi
  15. I cannot confirm the behavior for a "Backup" setting on the phone. Photos I delete are moved to the .SyncArchive folder like with a read-only secret. I am quite sure they will be expired from the .SyncArchive folder once they hit the time limit.