GreatMarko

Moderators
  • Posts

    3,174
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by GreatMarko

  1. You'd need to use "read only" secrets, rather than "full access" secrets. If you wish each "device" (family member) to be able to add new files, but only delete their own, you'd need to setup a series of folders, then assign each to be "full access" on just one device, and "read only" on all the others. For example, let's say 4 members of the family each have their own device, Dad would create a folder on his device called "Dad", with a full access secret. He would then give the read-only secret for this folder to the other family members, who would use this to create a "Dad" folder on their respective devices. Only changes that Dad makes to the "Dad" folder on his device will propagate. Changes to the "Dad" folder on other devices will not. Then, repeat the above on Mum's device with a folder called "Mum" - again, giving it a full-access secret on Mum's device, and read-only on all the others... then do the same for the other family member's devices. The result will be that you'll end up with a folder for each family member on each device, but only changes made to the respective family member's folder will propagate. Other changes will be ignored.
  2. There's a great big "Start New Topic" button near the top right of the forum index!!
  3. "Real time" monitoring works on all Windows OS's - I think, although I may be wrong, that Sync running on some Mac's (and possibly also on the Raspberry Pi?) have trouble detecting changes to files in "real time"? No, this means that existing files will only be "patched" is their size if LESS than 1000MB (files over this size won't be "patched" and will instead be re-transferred in their entirety if part of the file changes) See above! The number of files transferred concurrently depends upon the size of the file. From what I recall, "large" files are transferred one at a time, where up to 4 "small" files can be transferred concurrently. There is currently no way to change the number of files being transferred concurrently (although you can limit the up/down bandwidth used) There isn't currently a "mass deployment" tool as such. One possible workaround is to create a "portable" install on an USB memory stick, with all the necessary settings/folders defined, etc, and then copy/deploy this to each computer.
  4. You are correct - Sync is currently "closed source", and therefore protocol specifics haven't been released at this time.It is however based on - although a variation of - the original BitTorrent protocol.
  5. Full indexing happens when you initially add a folder to Sync. Once added, only subsequent changes will be indexed (i.e. the folder won't be completely re-indexed every time) Depends on the OS - not all are able to detect changes in "real time" - that's where the advanced "folder_rescan_interval" setting comes in - this defines a regular recurring interval at which to rescan your folders for any changes (that couldn't be detected in "real time") Sync will prefer LAN connections wherever possible. Where a direct/LAN connection cannot be established, a relayed connection will be attempted. If you wish to completely disable "relayed" connections, forcing Sync to use LAN connections only, you will need to disable the Relay, Tracker, and DHT settings This is answered in the Unofficial FAQ Correct. Sync will attempt to retrieve a file in the most efficient way possible - which will depend upon the speed of other peers. i.e. faster peers will upload more data than slower peers
  6. ...with either the "Search LAN" option (which sends out multicast "pings" on your LAN to detect other devices), or through using the "pre-defined hosts" settings
  7. Please remember that Sync is still in "beta" - this explains the frequency of updates, and also it's important to remember that not every "beta" build gets pushed via "auto-update". Once Sync leaves "beta", auto-update will function correctly, until then, you may need to manually download new "beta" builds from the links provided here
  8. This is a pretty old thread... but have you tried increasing the value of the advanced "folder_rescan_interval" setting? This is currently set to 600 seconds (10 minutes), and therefore, if your system is set to go to sleep after more than 10 minutes of inactivity, it's possible that it will never sleep. The solution is to increase the "folder_rescan_interval" setting and make it longer than the period of inactivity your system is set to sleep after
  9. Yeah, I can confirm that I've not experienced this issue with file sizes >4MB. The files sizes I've encountered this will have been typically <200KB in size
  10. Hmmm... Explorer doesn't usually generate thumbnails for unknown file types though!? For example, an "incomplete" image file being transferred by Sync would have a .!Sync, .SyncPart, .SyncTemp, or .SyncOld extension - i.e. "myimage.jpg.!Sync" The filetype in the above example is ".!Sync", it will only become a ".jpg" file once it has been fully received and the ".!Sync" extension removed. ...so what is Explorer doing trying to generate thumbnails for .!Sync, .SyncPart, .SyncTemp, or .SyncOld files? (I'm assuming of course that Explorer determines which files to generate thumbnails for based on their extension, not meta content?)
  11. ...in addition, release notes for the Mobile clients can also be found on the relevant pages in the Google Play Store and iTunes Store
  12. To be fair, I've not used Sync with any "serverfolders" on either WHS v1 or 2011, just regular folders that I've created myself outside of the Home Server Console, so yeah, that might be your issue! It would almost be like having Sync and say SkyDrive/DropBox monitoring the same folder at the same time - it's more than likely gonna cause issues! Have you tried manually creating a Sync folder outside of the Home Server Console? - does that resolve your issue?
  13. It's likely due to the fact that Sync is currently in "Beta" - therefore, some beta builds have a higher CPU utilization than others. I'd expect this to be addressed in a later, stable, build. However, in the meantime, the amount of CPU usage that Sync is related to the number of files being indexed/monitored/synced. Short of reducing the number of files you're syncing (not particularly practical), there are some advanced settings you could "tweak" that may lead to a reduction in your CPU levels. These include: Increase the value of "folder_rescan_interval"Set "lan_encrypt_data" to falseDisable "Search LAN"
  14. Yep - Sync installs and runs just fine on WHS2011 (it also runs fine on WHS v1 too!) ...so the issue you're experiencing is unlikely due to the OS itself
  15. It already is implemented on mobile clients - it's just not currently implemented on desktop clients, but as Kos has indicated, this will be implemented across all platforms at some stage.
  16. Yes, you could also do this. The method I outlined though would mean that you wouldn't have to manually remember/take note of which folders you were syncing and their respective secrets. Also, with the method I outlined, a re-index of each folder wouldn't be performed (which it would if you manually added a folder to a fresh install of Sync)
  17. The minimum OS requirements for installing/running Sync on Windows is Windows XP SP3 (32-bit) or newer (32 and 64-bit), so in theory, you won't be able to install/run Sync on earlier incarnations of Windows, including 2000, but the best way to find out would be to see if you can install & run it correctly!
  18. Yeah, I concur with @Bejay_Waddell - on the few times I've encountered this it's been with existing files that have just been updated, I've never experienced this issue with "new" files added to a Sync folder.
  19. Yes, this can be done, simply backup your %AppData%/Roaming/BitTorrent Sync folder before re-installing Windows. Once Windows is re-installed, perform a fresh install of Sync, and then with Sync not running, restore your previously backed-up %AppData%/Roaming/BitTorrent Sync folder. The next time you run Sync, all your previous Sync folders will be present in Sync! (assuming none of the original folder locations were lost during your re-installation of Windows)
  20. Sync is "distributed", therefore if you have 100 devices who all want the same file off a single device, that device will send a "chunk" of data to one device, and a different "chunk" to another device, and so forth.That way, each "chunk" of data will become available from multiple devices, meaning that not all 100 devices will need to get the same "chunk" of data from the single original device.
  21. Ok, try exiting Sync on your devices, then look for the presence of any .!Sync, .SyncPart, .SyncTemp, or .SyncOld files in the folders you were syncing and delete them. Then restart Sync on your devices. If Sync got "stuck" somewhere, this will likely resolve the issue and allow syncing to resume/complete.
  22. Are the files in the folder you're trying to sync currently open/locked/in use by other applications? If so, Sync can't sync your files until they are first closed in their respective applications.
  23. Try increasing Sync's advanced "folder_rescan_interval" setting - default is 600 seconds (10 minutes) - If your system is set to sleep where there's been a period of idle disk activity greater than this setting, your system will never sleep.