capi

I completely agree with this. I really hope they are going to reconsider this, because I am no heavy user and I already have more than 10 folders, yet the 40/year is a price tag I will not justify when most of my use-cases could easily be handled by rsync or unison or other solutions.

I need to agree with what people said: I fully understand all the other PRO features, but I am using more than 10 folders and for this feature alone I'm not going to be paying 40/year. Please reconsider this limit.

You can copy/paste the link and enter it in the key field, it will accept both, key and link.

More correctly: the more RW nodes you have. If you stick to RO nodes for backup, this won't be a problem. Bit-rot is a problem that needs to be addressed at several levels, unfortunately (but understandably), most filesystems ignore this issue and shift it to hardware, which often also skips checksum checks due to performance issues.

You can't because they have the key after the approval process. You can switch the secret on any other peer, but this might not be what you want. I think that there is a lot misunderstanding/misconception of what the peer approval is doing: it's not an access list, it just protects the exchange of the RW or RO-secret. Once a peer knows the secret, it can share it and anyone who directly enters a secret doesn't go through the approval process.

Not really, as after approval they see the secret and can share the secret directly, where no further approval is required. The approval process is primarily meant as replacement for/addition to the old "one-time key" feature.

Also, you can actually copy/paste the link into the "Enter a key" form, without going through the browser. This way it really works like the old "one-time" passwords, with the additional advantage of peer verification via certificate and a required approval of the new peer.

Yes, this is the intended backup functionality. If you want it otherwise, you can use the read-only secret of a share on the server. If a file changes on the mobile phone, it is also changed on the server, the old version going to the SyncArchive folder, where it is kept for how long you configured SyncArchive to be kept.

I sync a directory from a TrueCrypt container, which is not mounted all the time. As long as I don't mount it, btsync displays it as "Folder not found". Once mounted, it happly starts syncing. The drive is locked for unmounting, as btsync keeps an open file handle on several directories. I have not yet tried to force unmount of the container while btsync is still running.

That's a huge improvement for the link sharing feature. Kudos for making it work so fast!

I now checked the resizing issue directly on a Linux box: with Firefox the resizing of the columns doesn't work at all, with an ancient Chromium browser (Ubuntu 10.04), it works. So it just seems that the current solution simply won't work with the Mozilla engine. Hope this helps! Best regards, Capi

While the resizing columns on Windows 7 with IE works now, connecting to a Linux box with Firefox now cannot resize columns at all for me. When connecting to the Linux box with IE, resizing of the columns works, so this seems to be a incompatibility with Firefox. Google Chrome works, though. Best regards & thanks for all your efforts, Martin

This is the old one-time secret wrapped in a link, its not the secret itself that is being transferred via the link.

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.

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.

You'll most likely use a Linux version of btsync in a Docker container...

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.

Will those prefs be set to new files in the directory as well, or only to existing files?

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 tracker, but could not extract any shared data.

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

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

There are some UPnP implementations that are buggy. You can also disable UPnP in btsync, should fix the issue also.

@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.

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 removed once everything is fine and applied, but it is not temp in the sense that you should/could remove it on will. I have done my fair share of development with SQLite, and used WAL-mode a lot as it is a huge performance improvement in case of multiple writers and the advantage that a writer transaction won't block reader transactions.

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.