piotrnik

Members
  • Posts

    101
  • 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 of files over the last month or two in this state.
  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 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.
  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 disconnecting it).
  11. Does sync support files >4gb on android if using exFAT sd cards? or is it an android system limit?
  12. If windows, your drive letter may have changed. Try changing the letter.
  13. 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.
  14. 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
  15. 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).
  16. 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.
  17. 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...
  18. 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.
  19. 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.
  20. 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
  21. 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.
  22. 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.
  23. 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 if only something could be done about sync (1.3x) always using almost 300mb of ram...
  24. 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).
  25. For mine, it shows as downloading/data remaining while it's indexing, but nothing actually transfers and the amount decreases at it indexes.