piotrnik

Members
  • Content Count

    101
  • Joined

  • Last visited

Posts posted by piotrnik


  1. 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. 


  2. 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. 


  3. 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


  4. 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. 


  5. 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. 


  6. 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).   


  7. 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 :)


  8. 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).


  9. 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.


  10. 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. 


  11. 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...


  12. 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).