GreatMarko

Moderators
  • Posts

    3,174
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by GreatMarko

  1. This has now been added to the Unofficial FAQ
  2. A hidden .SyncID should be located within each folder you're syncing - not in the %AppData%/Roaming/BitTorrent Sync folder If the .SyncID file is missing/corrupt within the folder you're trying to sync, this will be the reason you're seeing the particular error you're seeing. Simply removing the folder from BitTorrent Sync and re-adding it again should hopefully resolve this issue and re-generate a new .SyncID file
  3. .SyncTrash folders can be found within the each folder you're syncing, but they can be "hidden" by the operating system. External Link: How to show hidden files in OS X
  4. Ah, I see! ...in which case, *.!sync files are ignored (i.e. if you place a *.!sync file in a folder you're syncing, it won't be transferred to other devices)
  5. "versioning" is planned for BitTorrent Sync! Yes, this has been raised a few times now in the forum (for example, here)... hopefully this will be addressed shortly!
  6. Check your .SyncTrash folder, as BitTorrent Sync, by default, doesn't "delete" files, it just "removes" them to hidden .SyncTrash folders There was a possibly related discussion on syncing "My Documents" and "My Video" folders, that may be of some interest
  7. BitTorrent Sync is currently in "alpha", and right now it does indeed have higher than you'd like/expect CPU and Memory usage across all platforms. These values also appear to be closely linked to the total number of files you're syncing (i.e. more files = higher CPU/Memory usage). The developers are certainly aware of the general high CPU/Memory issues that users are experiencing, and I'm sure some optimizations are in the pipeline!
  8. It's always very risky running two different backup/synchronization tools on the same set of files - I'd suggest using one or the other, but not both! There was a very active discussion on rsync recently that may be of some interest to you in helping you decide whether BitTorrent Sync or rsync is more suited to your particular needs
  9. SyncIgnore needs to be identical on all devices though - so you can't "ignore" some files/folders in a folder on one device, and other files/folders from that same folder on another device
  10. Not at present, you would need to share each sub-folder independently, rather than sharing the parent folder. This would allow you to select which sub-folders sync between which devices, as each sub-folder will have its own unique "secret"
  11. 1.0.132 is the latest version of BitTorrent Sync - please update, and see if this resolves your issue
  12. There is a correlation (on all platforms) between the amount of CPU usage vs the total amount of files being monitored/indexed by BitTorrent Sync - i.e. the more files you've added the BitTorrent Sync, the higher the CPU usage (even when apparently "idle" - as BitTorrent Sync is still "monitoring" files, even if it isn't transferring any) So, do you have the same number of files in BitTorrent Sync in 1.0.132 as you did in 1.0.116, or have you added more since you were using 1.0.116? - if so, this will be why you're seeing higher CPU usage Remember that Sync is still an alpha, I'm sure the devs will be working on optimizing CPU/memory usage before a "stable" release
  13. Have you tried updating to the latest version - 1.0.132?
  14. ..and how would you envisage this working if you're syncing between **multiple** devices - and not just between two!? ...have you checked the "History" tab? Hmm.. the ability to move/delete files around on drives/check how much free disk space you have, etc is kind of more a Windows file manager job! BitTorrent Sync's purpose isn't to be a complete replacement for your Windows file manager/operating system! Whilst there are plans to add "versioning" at some stage, which would then give you a "backup" solution of sorts... remember, that BitTorrent Sync is primarily a file ***synchronization** tool, rather than a complete backup solution. There is an active "wishlist" thread, though, where a number of users have voiced a desire to have more backup-orientated features, so feel free to post your suggestions there!
  15. You can click "Edit" at the bottom of your post and then the "Use Full Editor" button to change the thread title
  16. Are the clocks the same/correct on both computers? If not, this could account for the issue you're experiencing, as BitTorrent takes into account timestamps on files when determining which is newer
  17. The issue of retaining file permissions has been discussed in a number of other threads, for example, this one.
  18. This is only the case when updating, as rdebath has indicated, from 1.0.95 to 1.0.116. (I think, if memory serves, it was actually between 1.0.95 and 1.0.99 that fundamental changes were made to SyncApp (as it was then known!), which meant that folders had to be re-added). However, once you're on 1.0.116 for example, updating to 1.0.128, 1.0.130, or 1.0.132, etc WILL retain all your sync'd folders - you won't need to manually re-add them after every update!
  19. How deeply nested are the files you're trying to sync? Windows itself has a maximum path length of 260 characters (Source 1 | Source 2). If the combination of the length of the filename plus its path exceeds this length, this may be the reason it's not being seen by BitTorrent Sync. Looking at one of the names of your files "Svar på skjemaet "Online registration_ International Conference on Historical Linguistics Oslo 2013" er levert.eml" ...that's 116 characters alone without any path information!!
  20. Enter the copied secret into BitTorrent Sync running another device, and select a folder on that device you wish to sync with your original folder on your first device!
  21. The .SyncID contains the "internal ID", if you will, of that particular folder and is used to identify the folder to BitTorrent Sync - However, the actual "hash" of all the files within the folder (which is what BitTorrent Sync is monitoring in real time) is stored elsewhere (i.e. on Windows it's under %AppData%/Roaming/BitTorrent Sync) ...so if the hash is accessible but the physical source location isn't, BitTorrent Sync could infer that the source files have been "deleted" (rather than them simply being just "inaccessible" at that time)
  22. Actually, the current limit on the total number of files is 1 million - please see the Unofficial FAQ
  23. There's no "versioning" at present, but this has been requested a number of times in the wishlist thread. In terms of "accidental deletions" - such files should be automatically moved to the corresponding .SyncTrash folder, by default, rather than permanently deleted from the device. If BitTorrent Sync isn't able to finish completing a sync of a file, etc, it will be given a .!sync extension to indicate a partial/incomplete transfer. Once BitTorrent Sync does complete syncing of the file, the .!sync extension will be removed. BitTorrent Sync itself won't necessarily check if a file is corrupt or not when syncing. For example, you'll be able to sync a damaged/corrupt .zip or .rar file, as BitTorrent Sync won't perform any sort of integrity/CRC checking on the file - it just compares size/last modification time, etc.... and therefore, if your file is "corrupt", it will still sync
  24. This will most likely be due to the fact that your external harddrive is removable, and not always connected. I'm not sure BitTorrent Sync is currently able to distinguish between a removable drive that's been temporarily "removed", and a folder that's been physically deleted - and so to BitTorrent Sync they may both look the same! - Therefore, when you remove/eject a drive, BitTorrent Sync assumes that because it can no longer access the files in that location, they have been physically "deleted"
  25. ...but this only applies IF you're using the tracker server option - BitTorrent Sync will also work (i.e. locally within your own LAN) without negotiating via a central tracker server ...so individual BitTorrent Sync clients are capable of processing "secrets" themselves