mrmachine

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by mrmachine

  1. What is the point of common identity across devices, without the distribution of your folders across your devices? From a UI perspective, it will be just like 1.4?
  2. Default is set to be "Disconnected", so if anyone shares with me or if I create new shares owned by my identity, I can choose their location when I connect them. For the camera backup though, it seems that as soon as I selected the iMac from within the iOS app, it automatically connected it in the default directory as RO. I think before I did that it probably appeared as disconnected (because it shows on my MacBook as disconnected). So maybe I should have connected manually and chosen a location on the iMac instead of selecting iMac as a destination from the iOS app. But none of this answers
  3. I tried to delete a photo from my iPhone, but it stayed in the backup folder on my iMac. Also even though I only shared it to my iMac, it also appeared on my MacBook (because the whole BitTorrent Sync folder is shared). When I deleted the photo from my iMac as well (because it had been deleted on the iPhone), it was deleted from the MacBook but replaced with a bts link on the iMac. Double clicking the bts link showed an error about the file already being in the queue to sync and maybe I should pause some other folders. Not sure where it's going to sync from, though. It's been deleted from the
  4. Seems weird the on iOS Sync 2.0 it creates a 1.4 share on my other linked 2.0 devices. Also it has been made read only. But my ~/BitTorrent Sync folder is shared among all my linked devices, and it is also the default location for new shares. So now I have a read only ~/BitTorrent Sync/My iPhone Camera Backup folder that is inside the read write ~/BitTorrent Sync folder. I thought that was not possible? Is it going to bug out?
  5. 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.
  6. 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
  7. I don't care if the free version has a folder limit of 10. It's disappointing that you did go back on your word that pro would have new/additional features and free would retain existing features, but it's not a deal breaker. What is a deal breaker is paying a subscription fee for software where you only need to provide minimal infrastructure to facilitate it. In fact, one of the key features has been that users can completely bypass your infrastructure to ensure their privacy and to ensure that old versions will continue to work for as long as the binaries still run on the current OS versio
  8. 2.0.82 is the version I'm seeing the average speed problem on. After some problems with the alpha and beta, i decided to stay away from 2.0 and went back to 1.4.110 until 2.0.82 was released and I decided to try again.
  9. 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?
  10. I'm not talking about updating it a hundred times per second. It's pretty standard to update progress bars once per second, and it looks like that's what BitTorrent sync already does. I'm talking about providing accurate information when an update does occur (e.g. when it's not uploading anything because it's finished syncing, don't recalculate an average speed with 0 as the current speed), and showing always showing the current status (e.g. synced, syncing, indexing, etc.) Blank does not indicate that everything is synced. It doesn't indicate anything at all. 1.4 used to show a tick icon at
  11. It should *always* reveal the current status for a share, whether that is indexing, synced, syncing (%), etc. And when it does finally tell me something, I have so little confidence that it's actually telling me the truth. For example when I start syncing a large folder, it might say 5MB/s uploading, but then after the sync has finished and it's not actually uploading anything anymore, it still reports that it is uploading but the speed drops down every second (guessing the value only updates once per second) until it disappears. Looks like the app is reporting an average speed over the
  12. 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
  13. Now that 2.0 is out, I finally upgraded. My two devices (iMac and MacBook) are syncing all the same folders as before, and they are all marked as "1.4". Both devices have the same identity. Now apparently "classic folders" don't support some of the features that 2.0 folders support. Like what? All my devices are 2.0 -- so why is the share still 1.4? How do I get it to "upgrade" so I can take advantage of the new features for existing shared folders?
  14. 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
  15. 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
  16. So because "Icon?" is ignored, folders named "Icons" is also silently ignored? I agree this is a problem and surprising behaviour...