mrmachine

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    1

About mrmachine

  • Rank
    Advanced Member
  1. Would you mind sharing what those other solutions are? I've recently talked with the creator of CCC and it offers some protection against bitrot on the destination volume, but still has the same problem of propagating corruption on the source to the backups.
  2. I don't use Sync as backup. I have CCC to an external bootable HDD and Arq (to the ZFS NAS) for that. But if Sync will propagate bitrot to the ZFS NAS, because ultimately all the machines I actually use daily don't have any protection against bitrot, then it's still a manual process of discovering the rot to begin with, and then searching incremental backups for the last good copy. Doesn't Sync periodically index all its shares to determine if it is missing any files from the pool and sync them? I seem to recall with BitTorrent in general, if you modified some local data the torrent app woul
  3. So there's basically nothing that can be done about it... All devices need to have protection against bit rot for the pool to be safe?
  4. Getting back to the feature request, is there any chance the BitTorrent Sync could propagate bit rot to other clients? I have a ZFS NAS where I store most things, so I feel safe that it is protected against bit rot. But I want to sync some of its files to an iMac and a MacBook, which run JHFS+ file systems, which are susceptible to bit rot. If my iMac or MacBook do suffer from bit rot, is there any way that BitTorrent Sync will detect that as a legitimate change and sync the corrupted file it back to the ZFS NAS and all other devices, thereby negating the bit rot protection provided by ZFS
  5. It would be great if BitTorrent Sync allowed earlier general patterns to be negated by later more specific patterns. This would allow users to choose between whitelist and blacklist behaviour for IgnoreList and StreamList. For example: # whitelist, only sync streams listed below com.apple.metadata:_kMDItemUserTags com.apple.ResourceForkcom.apple.metadata:kMDItemFinderComment% # blacklist, sync all streams except any negated below*!com.apple.FinderInfo Also, support for double asterisk glob pattern matching would be great. For example: # IgnoreList/Some/**/Path Would match both: Some/Foo/Path
  6. Currently, a folder is shared and will appear on my other devices (using their default sync setting) as soon as I add the folder to share or select "Share folder with BitTorrent Sync Alpha" from Finder. It will appear in the default folder (if default sync setting is "connected" or "sync") with the same name as on the system it is being shared from. It can be renamed on the other devices once it is sharing, or its destination can be chosen if the default sync setting is "available", but using the same name as the existing folder as the default can be confusing. For example, if I have sever
  7. So because "Icon?" is ignored, folders named "Icons" is also silently ignored? I agree this is a problem and surprising behaviour...