• Content Count

  • Joined

  • Last visited

Everything posted by piotrnik

  1. I'm also seeing this on Android (running Pie) and Windows 10 x64 over multiple folders and devices (with different folders on each device)
  2. 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
  3. 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.
  4. 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.
  5. 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).
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. 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 disconne
  11. Does sync support files >4gb on android if using exFAT sd cards? or is it an android system limit?
  12. 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.
  13. 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
  14. 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).
  15. If you change a synced file on a RO node, it will break the sync for that specific file and subsequent changes from the RW side won't sync over (unless you have the overwrite changes option checked for that folder, in which case it will undo the changes as soon as sync notices). If you add a file on the RO node, it's totally ignored by sync.
  16. Sync breaks the files in pieces for transmission, so it probably just fills the buffer with the currently-transferring pieces of whatever files are currently transferring. just a guess on my side though...
  17. Sync remembers the IPs of your peers for a while after you last connect. It's possible that tmobile is blocking the connection to the central tracker, but since your peer already had the right address for the other peers, it was able to get to them. It's a bit of speculation on my part, but could explain the behavior.
  18. I did something similar with synctoy -> btsync. It was able index the folders without sending data, found they were in sync, and has kept them that way since.
  19. It's the selective sync feature that they're referring to, not a folder size limit - ie if you have a 2tb folder, you can still "sync" it on a 350gb laptop, and just download files as-needed, instead of needing to have a full copy of all the files on it to access them. Currently this is not possible on the desktop versions
  20. It would probably depend on the hash of the file as well as the mtime. I know in the past there have been issues with sync overwriting other nodes when changes were made while a node was offline - once the offline computer came back on, it's files were seen as the most recent (though actually older), and overwrote the newer files that were updated while it was offline. You may run into something like that.
  21. you could try enabling a whole-disc encryption for your android phone (like bitlocker on windows). I think that would be your best bet to making a sync share that is encrypted on both sides and yet still accessible and transparent to sync.
  22. If keeping the folders synced as soon as possible isn't too big of a deal, you can also lessen system impact quite a bit by increasing the interval to a few hours (especially with huge synced folders). I did this (mostly just pictures/documents synced to offsite backups - it's not so important specifically when it gets backed up/synced, as long as it happens a few times a day), setting it to 10-12hrs, and it seems to be working quite well with much less frequent cpu load and disc access. I'm running windows, so the vast majority of things are still noticed and synced immediately. Now i
  23. The encrypted function is more for storing data on others' computers (or on rented server space), since the host computer is unable to read it. A good example being two friends that shared a few GB space for each others' sensitive data - each doesn't want the other looking at it, so it's encrypted. However, the data is still there on the other computer. If their own HDD died, it will restore to their side unencrypted once they choose a new folder and set up btsync right (provided they still have the proper key).
  24. For mine, it shows as downloading/data remaining while it's indexing, but nothing actually transfers and the amount decreases at it indexes.
  25. 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