capi

Members
  • Posts

    70
  • Joined

  • Last visited

  • Days Won

    1

capi's Achievements

Advanced Member

Advanced Member (3/3)

  1. 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.
  2. 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.
  3. You can copy/paste the link and enter it in the key field, it will accept both, key and link.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. That's a huge improvement for the link sharing feature. Kudos for making it work so fast!
  11. 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
  12. 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
  13. This is the old one-time secret wrapped in a link, its not the secret itself that is being transferred via the link.
  14. 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.
  15. 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.