piotrnik

I'm also seeing this on Android (running Pie) and Windows 10 x64 over multiple folders and devices (with different folders on each device)

I'm also seeing this quite frequently on several of my machines. Do we have any information on this or possible resolutions? I can copy a file into a folder on Machine 1 and Machine 2, 3, etc will sometimes throw the error and refuse to download it further. It happens with all types and sizes of files. Sometimes I can remove the file from the folder in Machine 1 and then readd it after the others notice the change (they'll eventually remove it from the "files cannot be downloaded" list), and then it'll sync ok. This is impractical though as my shares have accumulated dozens of files over the last month or two in this state.

Make note of the read-only key, remove the folder, re-add the folder with the read-only key, and once it indexes, it will be as you wish. I've done something similar a few times, and it works great.

If you give all the computers a read/write key, when anything is changed on one, it will sync to the others. Alternately, if you give your master computer a read/write key, and a read-only key to the others, anything you change on the master will sync to the others, but anything changed on the others will not sync back to the master.

you should be able to remove the folders from the ones you want to be read-only, then take the already existing read-only key and readd the folder (rather than generating new keys). having only read-only keys in your syncgroup can cause weird things (at least one should be r-w).

From what I understand, Android can't generate r/w keys from the app. However, you can create a sync on a desktop/laptop, copy the r/w key to the android device (or via QR), and then have the expected r/w behavior. I believe native android r/w key creation is on the list of future improvements

It's normal for read-only peers to send data both for sync status (eg checksums and other transfer-related info) as well as sending parts of the actual files to other peers that are missing them. Because they are read-only, they won't sync any files that are changed on their side, but they will sync any unchanged files transferred from the read-write peers. As an example, assume there is one r/w peer (A) and two r/o peers (B and C). A will send files and changes to B and C. B and C will share any files (unchanged on their side) between themselves (if A sends it to B, B can forward it to C instead of C having to get it from A). If a new r/w or r/o peer is added (peer D), it can get the files from any combination of A, B, or C. By the nature of the torrent system, any peer can get any file pieces from any other peer that possesses them. Sync adds r/w and r/o levels, but doesn't change this default nature of torrents - the r/w or r/o only affects who can make changes that propagate out through the system, not how the changes transfer between peers.

I've done something like this with a calibre library. As long as it's only open on one computer at a time, it seems to work fine - the library database files are in the synced folderset, so the calibre on the other computer doesn't notice the change when it's opened later.

The tracker helps your computers initially get in touch with each other, and is not needed thereafter. On the same wifi network it shouldn't be needed. Relays help if a direct connection can't be made between the computers (usually due to firewall issues). This also shouldn't be needed on the same local network. Relays can slow down the transfer considerably (bandwidth is limited), so as long as your computers can make a direct connection, it's actually faster to turn them off.

If sync is running and connected between the three, yes (assuming stolen computer has r/w permissions; nothing will happen if it has r/o). To avoid this, change the keys on the non-stolen computers if one is stolen (or the key compromised by any other means). There will apparently be a feature in the forthcoming pro version that would allow someone with a new "owner" level permission to remotely disconnect the stolen computer, but there's nothing automatic like that now (also, no word on if the pro version would allow deleting data on the compromised computer as well as just disconnecting it).

Does sync support files >4gb on android if using exFAT sd cards? or is it an android system limit?

If windows, your drive letter may have changed. Try changing the letter.

Indexing is controlled by the local client, so your computer shouldn't even notice a difference if you move it to a new physical location. It would be just like getting a new IP if your ISP is on a dynamic system.

Unfortunately for your situation, until the pro version with more granular permissions, sync treats all peers as being on the same level - everyone with r/o is the same, and everyone with r/w is the same. Thus if you give r/w access to someone, they have all the same rights as you - in other words, they can also give the key (r/w or r/o) on to others, change any file, etc, just like you can. As the system works, they are now indistinguishable from you. If you give r/o access, the same concept applies, but on a lower level. They likewise have access to all the files, but changes made don't sync back to the r/w peers. Like the r/w peers can share either the r/o or r/w keys, the r/o peers can share the r/o key as desired (they can't share the r/w key because they don't know it). As mentioned by RomanZ, the link/one-time key/approval only serve to secure the transmission of the core r/o or r/w key; they have fulfilled their purpose once the new peer has access and have no further effect. Currently, the only way to revoke any access for unwanted peers is to change the folder key on all computers that you want to retain access. The peer with the old key will still have all the files they downloaded/synced (and connections with anyone still using the old key, such as by sharing the key on their side), but no new changes will sync with other peers on the new key. Pro will apparently add another level (the owner) on top of the r/o and r/w tiers, and they will have the ability to revoke access already granted (though it's not currently clear if only the owner has to be pro and the users can be free version, or if they all have to be pro; nor is it clear if revoking access will also come with an option to delete the data on the revoked peer). Hopefully this will help explain things a bit

You could check your network properties option (if in windows) to see what speed the wifi card is actually operating at (I usually get 70-100mbs on a 300mbs 802.11n router because of moderate signal). On top of this, the network speed is measured in Mb/s and transfer speeds at MB/s (divide by 8 to go from Mb to MB). On the above network I can usually send/receive in-network at 6-9MB/s, which is using 48-72Mb/s of bandwidth (reserving some for overhead and web browsing).