piotrnik

Something like the celeron Intel NUC may fit what you're trying to achieve - low power, low footprint, (relatively) low cost, but with a bit more power than a pi

I believe this is an android/linux thing - "android.txt" is not the same file as Android.txt" like it would be in windows, and this affects capitalization similarly. I have similar issues with several file explorer apps on android.

You will need to set up the folder initially from a computer, and then add the read/write key on the mobile devices. Both should then be able to sync between each other, and the folder can be removed from the computer side once set up on the mobile devices (for now a computer is just needed for the initial setup).

There are also threads in the feature request forum asking for exactly this.

It will need to re-index when the files are used by another btsync install, but should notice any files that match and not re-transmit those. I did something similar with my ~3TB setup - I copied it locally over to a HDD, installed the drive in another computer, installed btsync and synced the directories. It took forever to index, but didn't copy anything over, and subsequent changes have synced correctly.

Did you choose "backup" for the phone, or "read-only"? The android app treats those as different things (and the difference is only available on the phone so far). read-only works as it does on the computer, but backup allows you to remove items from the phone and not have them be removed on the computer side.

I also still use 1.3x for UI reasons. Likely as long as it continues to work, and unless the UI changes to be more useful, I'll stick with 1.3x

Yes, exactly. Once you approve it, the folder is added to their sync with the specified RO/RW permissions. Also, once they have the folder listed in their sync, they can get to the secrets (to share them further, if that's a concern). The approval is really more of a additional security layer on top of a one-time key, not a continuing security measure.

From what I've seen, moving across secrets/folders usually results in a delete/resync, rather than just a move. Usually BTSync is good about catching a move inside a secret/folder, but it doesn't seem to do well with moves across folders.

As far as I'm aware, using the link to approve the add only is effective for that one use (or however many uses specified) - the secret can otherwise still be shared manually by any peer (by the approved peer as well, once the link is used), and there's not really a way to prohibit people aside from a certain whitelist from connecting to a certain folder/secret. The only exception would be if each member of the group were manually set to only connect to the other members, with no dht/tracker support. I've not tinkered with manual settings or the approval process much, so take my words with a grain of salt, but that's what I've gathered from the forums here.

You could extend the rescan interval in advanced options. I believe the default is 10 minutes, which would cause spinup (or to not spin down if shorter than your sleep interval). You could extend it to 2-4 hours. There is the downside that it may not recognize changes and not start syncing until that automatic rescan though, just so you are aware.

I would also appreciate an option to rename folders without changing the actual physical name.

I do think something like this would be nice, but I also agree that it's kind of against the design philosophy of BTSync in the first place - peers are equal, and it's not a client/server setup.

The key with a single use prevents the key from being intercepted and used. Its purpose is secure transmission, not security from the recipient. Once the recipient installs the key (or uses the link), they are granted equal status with any other peer with their same access. In other words, a read-only peer who is given a one-time-use link ends up the same as any other read-only peer once the link has been used, and can access all the files and keys of its privilege level. If you are giving the key to an untrusted peer, this does mean that they could share the key further if they want (though only the read-only key if they do not have read-write access). There are only two levels of access - read-only and read-write. The only way to remove access for one specific user is to change the keys on the other computers manually.

I also would like to add my vote, for the same reasons as snv above.

This is more or less how btsync is intended to work. One-time keys/links are meant more for security during transmission (from people eavesdropping on the line), rather than ongoing security. BTSync doesn't have a client-server configuration (where the owner can change/revoke access), it has a peer-peer configuration (where all peers are all equally trusted and have equal access to their respective read-only or read-write keys, with the exception that read-only peers cannot see the read-write keys).

Are you looking for help with the utorrent/bittorrent program, or the btsync program? This subforum is for the btsync program.

I believe the .syncignore file should be only in the root folder. Inside it, you would put the path to the "bob" folder (ie \folder 1\subfolder\bob) and it should then ignore the folder.

I would also second everything said above - great product, excellent improvements for the most part (especially proxy, easier encrypted keys, and link sharing), but not a big fan of the interface. it also seems slower than the other (non-IE) interface.

You can't add any non-BTSync folder on kitkat and higher as read-only or read-write. This is because BTSync creates the .sync folders/files in all folders added to it and stock kitkat (ie without an access patch) doesn't allow apps to change any folders outside of their own.

you will need to use the key (as in the screenshot a couple posts above) to sync a folder in 1.3.109

If I understand right, once the share is approved, you can't remove access to the folder (except by changing the secrets on the other computer(s) in the share, as with BTSync previously); the expiration date only controls when the link itself expires, not the resulting access. One question that I do have - if there are multiple computers on a share, is it only the computer that generated the link that has to approve it, or do all computers on the share have to approve it?

From what I've noticed, it tends to go alphabetically for my shares. It may be different for you depending on version and OS though.

If you did a full sync between the two, everything only on server 1 would be copied to server 2, and vice versa (BTSync doesn't transfer files that are already the same). Changes on either side would sync over to the other one (similar to the 'synchronize' option in synctoy. If you did a read-only sync from server 1 to server 2, everything only on server 1 would be copied to server 2, but nothing from server 2 to server 1 (kind of like the 'echo' behavior in synctoy). Once the sync is complete, if you change a file on server 1, the changes would sync to server 2. Any files (or changes to files) that were only ever or server 2 will not be synced to server 1. Additionally, if you change one of the synced files on server 2, it will break the connection with server 1 and no longer be updated from there (unless you have the option to "restore modified files" checked, in which case it will delete the modified file and transfer a new copy from server 1). Unfortunately (or fortunately, depending on your goals), if you did a read-only sync from server 1 to 2, BTSync will not remove anything that is only on server 2. So say server 1 has files A and B, and server 2 has files C and D. After a read-only sync from server 1 to server 2, server 1 will have files A and B (as previously). Server 2 will now have files A and B from the sync, and then also its original files C and D. Any future change to file A and B from server 1 will sync to server 2, but if files C or D are changed on server 2, or file E is added to server 2's folder, none of those changes will sync to server 1. I think there is a feature request thread that read-only folders remove non-synced items (in the example above, with this feature BTSync would remove files C and D from server 2, to keep it in strict read-only sync with server 1). However, this is not an option in sync right now. There is also not a 'contribute' option per se in BTSync, where it would only add/change the files and keep files deleted from server 1. There is a sort of workaround though. Deleted files are moved on server 2 to the .syncarchive folder, and remain for however long they are set in the options; I believe using '0' for the number of days option there allows them to remain forever (assuming enough disc space) - kind of a workaround to get 'contribute'-like functionality.

you may be able to do ctrl+ or ctrl- to resize text, since it runs as a web/html app.