GreatMarko

Moderators
  • Posts

    3,174
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by GreatMarko

  1. Yes, BitTorrent Sync does work on Windows Server 2008 R2!
  2. Yes, you can use the wildcards "*" and "?" in your .SyncIgnore files to exclude specific files and folders.
  3. What version of XP are you using? BitTorrent Sync requires at least service pack 3, and isn't supported on 64-bit versions of XP
  4. Ha! Tell me about it! I've been publicizing the public availability of BitTorrent Sync on some other forums this afternoon, and the overwhelming concern amongst those who haven't heard about BitTorrent Sync before is the common misconception surrounding the word "torrent"
  5. I beg to differ! I currently sync between 7 devices (including two always-on WHS's) 1) You can change the ports that BitTorrent Sync uses, as well as choose TCP over UPD - it would be difficult for an ISP to completely block BitTorrent Sync 2) You can separately limit the upload/download rates of BitTorrent Sync - so you can easily tailor BitTorrent Sync to your connection speed/available bandwidth I may be wrong, but doesn't RSync only transfer a single file at a time? BitTorrent Sync can transfer multiple files concurrently! Give BitTorrent Sync a go! You'll then be able to more accurately determine its capabilities/performance when compared with RSync!
  6. Yay! - BitTorrent Sync has now gone public! Anyone can now download the latest builds at http://labs.bittorre...ments/sync.html If you're still waiting for an invite to use BitTorrent Sync, or want the latest build, the wait finally is over! Just head to the above URL to download! The latest build number is 1.0.116 Happy days! Note: BitTorrent Sync still remains in "Alpha"
  7. As kos said, "It talks with the peers to see if something was changed in the folders, so peers could exchange with changes they might have" i.e. this communication happens continually regardless of whether any of your files have changed - so even if no files have actually changed on the device you've been focusing on, BitTorrent Sync will still have to check for changes to files on other devices you're syncing with, etc.
  8. Always nice to see a fellow ex-Mesher come to BitTorrent Sync! Yes, you are correct - this activity is due to BitTorrent Sync connecting to the tracker every few seconds to get a list of peers. To my knowledge there isn't currently a setting to change this interval, although, you could try unticking the "Use tracker server" option on each of your shared folders. If all your devices are on the same LAN, you could also untick the "Use relay server when required" option to further reduce network traffic. If all your devices are have fixed IP addresses, you could further untick the "Search LAN" option, tick the "Use predefined hosts" option, and then list the corresponding IP addresses of your devices. Again, this should further reduce network traffic.
  9. Yeah, I'd say that's probably normal - I get a 3-11% constant CPU usage from BTSync on one of my quad core machines. Again, the amount of CPU usage does also depend on the actual number of files BTSync is continually monitoring. In my 3-11% constant CPU on a quad core case, BTSync is monitoring over 170,000 files(!)
  10. Knireis, Please see this topic and this topic. In a nutshell, according to the BitTorrent Sync team: "Sync rescans folder every 10 minutes, to make sure there were no changes missed ... We plan to make this interval configurable."
  11. There were known issues syncing >100,000 files on earlier builds on BitTorrent Sync (then called "SyncApp"). I'd suggest updating to the latest available build (1.0.116), as this will likely resolve your issue!
  12. There kinda already is in a way - just click the "Like This" button at the bottom of relevant forum posts! - When the BitTorrent Sync team browse this forum (which they regularly do), they'll be able to gauge how popular certain suggestions are based on how many "likes" a post has!
  13. BitTorrent Sync doesn't only access the disk when syncing, it also accesses the disc to index files! If you've added a large number of files to BitTorrent Sync - even if they're not currently syncing with any other devices, you will still see a higher CPU load. How many files are currently being indexed by your BitTorrent Sync? For related information on high CPU usage, please also see this topic and this topic.
  14. The "Check for updates automatically" option and the "Check now" button were, to my knowledge, not implemented in 1.0.75, and so 1.0.75, will always tell you that your client is up-to-date - even though it's not! As rhd pointed out, the latest build is 1.0.116, and in addition, the name "SyncApp" has been dropped in favor of "BitTorrent Sync". If you've not been given a link for the latest build, you could try emailing sync@bittorrent.com and asking very nicely for one! Also, be aware that current builds of BitTorrent Sync are not compatible with SyncApp 1.0.75, therefore be sure to make a note of all your shared folders/secrets, etc, as these will have to be re-added if/when you update
  15. Yes, they should! Perhaps it's a firewall issue on one/both machines? Also, are the IP addresses of both machines in the same range? You could also try changing the advanced setting lan_use_tcp to "true", which will force BitTorrent Sync to then use TCP (instead of UDP) for connections
  16. 2jFXHjJF, those are not really issues - more feature requests, but anyway: There are already plans for an API. Please see this post This already exists! You can use .SyncIgnore to selectively sync files, and there's also an option for "Read Only" secrets BitTorrent Sync is already compatible with x64 Windows platforms, with the exception of Windows XP 64-bit, and there are no plans for a x64 WinXP client, given that this is nearly an obsolete OS (XP will no longer be supported by Microsoft from April next year!)
  17. I think you may have answered your own question there! BitTorrent Sync is first and foremost a synchronization utility. Whilst connections (and data transmission) between devices are encrypted, BitTorrent Sync won't process/alter the contents of the actual files themselves i.e. the file sent will be the file received. To share/sync a file but not have the recipient be able to access/open it, the best option would perhaps be to use a 3rd party tool/application to first "encrypt" the file at source before syncing it. .zip or .rar files, for example, offer encryption & password protection and have the additional benefit of compressing data too (potentially faster syncing!). For those concerned about files containing "clear text" being sync'd, perhaps WinZip, WinRAR, 7Zip, or one of the many other compression/encryption solutions out there could be of use to protect sensitive files prior to syncing/sharing. I'd be surprised if the idea of having a special "secret" that would "convert" files being syncd into another, encrypted, file type at the destination makes it into BitTorrent Sync - not only is this a bit beyond the scope/purpose of a "synchronization" utility, but it would also present a number of challenges, particularly with a R/W sync - for instance, let's say on device A you have a file that you want to arrive at device B as another file i.e. in some "encrypted" format. How would BitTorrent Sync keep tabs on these two different files given that they won't then be identical in terms of name/size? You could end up with a loop/cascade/race condition, i.e: Unencrypted "File 1.txt" on Device A is encrypted by BitTorrent Sync and arrives as "File 1.rar" at Device B "File 1.rar" on Device B then sync's back to Device A as "File 1.rar" "File 1.rar" on Device A is encrypted (for a second time!) and sync's back to Device B ...and so forth! However, one potential solution to achieve what you're trying to achieve would be to use the command line interface of something like WinRar, and a batch file scheduled to run on a recurring interval. The batch file would automatically create encrypted .rar files of the individual files within the monitored folder. The same folder could also be added to BitTorrent Sync, and by making use of the .SyncIgnore feature, ignore (not sync) everything other than .rar/.zip files. This would essentially achieve the automated "encryption" you're after! In summary: Unencrypted files are placed into a folder A batch file runs and automatically creates - in that same folder - password-protected .rar archives of the files BitTorrent Sync is set to only sync .rar files from that folder (and ignore all other files) ... but again, I think it's a bit beyond the scope of BitTorrent Sync to be able to provide this kind of file encryption itself.
  18. The latest builds of BitTorrent Sync (formally SyncApp) don't allow running multiple instances (on Windows at least) It may be possible that earlier builds did allow multiple instances, and also there is a case where you can have two copies running (i.e. if you've got both "SyncApp" AND "BitTorrent Sync" installed at the same time), but as I say, the latest builds of BitTorrent Sync don't allow multiple instances on Windows (I can't speak for Linux though)
  19. kos, it would be great if, when implemented, this setting could be on a per-folder basis, rather than just a generic global setting. For example, you may have a folder whos contents wont change more than once a day, and another folder whos contents is expected to change every couple of minutes, etc
  20. On the Devices tab of BitTorrent Sync, what does the icon show adjacent to your pi device? If it's a cloud symbol, BitTorrent Sync isn't currently connecting to the device directly via your LAN - which might explain why your transfer speed to the pi corresponds to your internet speed. Check the Folder Preferences of the folders you're trying to sync. If you disable the options for relay/tracker server, this will force BitTorrent Sync to try to make direct connections to devices when syncing that folder. Additionally, you could potentially make use of the "predefined hosts" settings to manually specify the IP address of your pi, which BitTorrent Sync will then consider "local". If all that fails, and BitTorrent Sync is able to connect to your pi directly but you're still experiencing slow speeds, try disabling the advanced setting lan_encrypt_data, and enabling the lan_use_tcp setting. Disabling encryption and enabling TCP in LAN can increase transfer speed.
  21. I know the team have previously made some improvements in the area of CPU usage - see this topic. So, I would expect (or rather hope!) that further CPU and Memory optimizations can be found before the first public release of BitTorrent Sync. From my own testing, the amount of CPU usage also appears to be directly linked to the total number of files indexed by BitTorrent Sync. i.e. on devices syncing a several thousand files in total, the CPU (and memory) usage is considerably higher than than devices only syncing a couple of hundred files total. (i.e. 25% CPU & 221MB Memory vs 5% CPU & 13MB Memory) There's also been a related discussion on high CPU/Memory usage here.
  22. According to BitTorrent, there will be a changelog once BitTorrent Sync goes public. Please see this topic.
  23. As kos previously reported earlier in this thread, this was a mistake in the user guide, which has since been corrected. So to clarify, if lan_encrypt_data is set to "true" BitTorrent Sync WILL use encryption in the local network
  24. See this topic. ...in a nutshell, BitTorrent Sync will remain free!!
  25. Isn't this the same as the "one-time secret" option that already exists in BitTorrent Sync?