mrmachine
-
Posts
38 -
Joined
-
Last visited
-
Days Won
1
Posts posted by mrmachine
-
-
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 the question about RO share within RW share. I thought this was not allowed, but Sync has allowed it (and actually done it for me automatically). Are there definite known problems with RO shares nested inside RW shares?
-
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 iPhone and is not on the MacBook either, so it can't sync from anywhere.
Not all of my shares are located in the BitTorrent Sync folder. A couple are elsewhere on the file system, but generally I want to just share that one folder among all MY linked devices, and I want to share (with RW or RO permissions) to other identities (e.g. wife) only SOME of those sub folders. This behaviour is just like dropbox. I don't want to have to create a new share for every single folder inside BitTorrent Sync folder to get it appearing on all my devices. I just want to put anything in that folder and have it sync.
-
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?
-
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.
-
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 would detect the block was not right and re-download it?
If during a reindex, Sync detected a mismatch, how would it know whether or not to propagate the change to other clients, or re-download the file from other clients?
For example, say I shut down Sync on one device, modified a file but left its file size and mtime the same. When I started Sync, I assume it would re-index all the shares. Would it "fix" my altered file by replacing it with data from other devices, or distribute the modified file to other devices?
-
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 version.
I would happily pay a fee to purchase the software. I'd even pay micro-transactions to unlock specific features. I'd also pay a higher but one time "lifetime" price, if you insist on going for subscription pricing. But if it's subscription or nothing, then I'm afraid it will be nothing.
If the sales pitch for the subscription pricing model is that users get new features because developers get paid every year, how is that any different than the old perpetual licensing model? The difference seems to be that users are locked-in, because if they eventually decide that the new features are no longer worth the annual fee, not only do they miss out on the new features but they lose all access to existing features that they already paid for and would like to keep using.
-
I agree I also miss this little tick
But I think I know what you mean and I wonder if it is still occuring in the latest version, which is 2.0.82 from this day.
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.
-
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?
-
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 least when it was synced.
-
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 last 5 seconds or something, and it takes 5 seconds after syncing finishes to stop doing so during which time it's reporting bad data.
I don't understand how/why it can't just accurately report the current status in real time?
-
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?
-
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?
-
I even searched for and updated all files with future timestamps, and then restarted BitTorrent Sync, and it still says 21 years...
-
I added two folders to two devices. The contents of the folder were the same and around 130GB. Even after many hours (on same LAN) the UI says "status" is either "Out of sync", "Out of sync - indexing" or "Sending" or "No peers online".
Even when it says "No peers online", the "peers" column says "1 of 1 Peer" and when I click it says it has 48GB to upload to the peer.
Even when it says "Sending", the "sending" and "receiving" and "progress" columns are all empty.
Even when the peers modal says it has 48GB to upload to the peer, status is just "Out of sync" and nothing is in "sending" or "receiving" or "progress".
Sometimes "receiving" or "sending" or "progress" (or any combination thereof) shows some activity, but the "status" is not "sending" or "receiving".
This makes it very hard to trust that BitTorrent sync is actually doing anything at all, or to trust that it is doing what it says it is doing (when it says it is doing anything).
Why is it so random and unreliable?
This is on 1.4.110.
-
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.FinderInfoAlso, support for double asterisk glob pattern matching would be great. For example:# IgnoreList/Some/**/PathWould match both:Some/Foo/PathSome/Foo/Bar/PathIt would avoid the need for users to have to know and count exactly how many levels of depth need to be ignored. For example:# IgnoreList/Some/*/Path/Some/*/*/PathLikewise, it should be possible to negate these:# IgnoreList/Some/Path/*!/Some/Path/Foo -
@mrmachine
Many of MacOS streams are computer-specific and are not valid on other computers. The FinderInfo is a good example - if synced, every Mac is going to fix it is only valid for one computer - which forces Sync to transfer it again and again. You still can allow synchronization of all streams by putting "*" into SyncStreams, though it is not recommended.
For the setting a global list of Streams - it sounds like a feature request. Mention it here so it won't be lost.
If I allow all streams to sync with "*", can I then subsequently negate some streams with a more specific rule? Much like Synching allows a more general match to be negated by a more specific one with a preceding "!". This would allow users to choose either whitelist or blacklist behaviour. E.g.
# 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 -
Indeed... The mtime shouldn't make a difference to the date synced... In my case it says "in 21 years"
-
The ".bts" links are NOT analogous to the traditional "selective sync" option that many people are asking for. It is a great feature for sure, but it is very different in behaviour.
-
Seems that the default list of xattrs mentioned in the KB and this thread has changed. It no longer syncs FinderInfo, and a few others. The default is now only:
com.apple.metadata:_kMDItemUserTags
com.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentI am only syncing between OS X Yosemite clients, and I would like to make sure that all folders sync as many xattrs as possible, excepting any that are detrimental. Specifically, I like to set alternative folder icons and I'd like these to be synced rather than having to set them again on every client.But I have about 10 folders shared, and even just updating the white list to include the required xattr is somewhat annoying. I don't even know what is the required xattr for folder icons? Why can't StreamsList be set to allow all by default with exceptions that are ignored, rather than a white list? Alternatively, it'd be nice to be able to set the StreamsList as a global device/client setting instead of a folder/share setting. If the device is capable of using the specified xattrs, then all shared folders should sync them. -
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 several "Backup" folders, one for each client or server, and I want to share one of them, the first will simply appear as "Backup" with no indication as to which client or server it is for. And if I then share a second with the same name, I'm not even sure what would happen.
When a folder is selected to be shared, instead of opening the share dialog immediately (email/copy/QR), it should first ask the user what name remote devices should use for the share. It can default to the current folder name, but the user should have a chance to change it and then hit "OK" or "Share" or "Add" to confirm it. Then I could rename "Backup" to "FOO Backup".
Any new devices that are linked to my account should start syncing it (depending on the device settings) as "FOO Backup", regardless of what any other devices have renamed the folder to.
I should also be able to change the default share name at any time from the preferences for that share. This would avoid the problem Dropbox has where you can rename a share on your local device without impacting another device, but you cannot rename the actual share name on Dropbox which is used as the default share name for new devices. You have to disable sharing, rename the folder and re-share it.
-
If you want create but not write or delete permissions, you could add a second "Public Dropbox" share which has read/write permission, and setup rules on one computer (your main one) to automatically move files out of that directory and into the other directory which you are sharing as read only.
-
Definitely, it would be great to have an easy to use GUI to manage SyncIgnore, rather than having people edit the file by hand. It should include a collapsible tree view of all files and directories in the share (whether or not they are synced to this device). All files should be checked by default, which means they are NOT included in the SyncIgnore file. If a file is unchecked by the user, then it is added to the SyncIgnore file. This should only affect the current device. The UI could also have a second area where users can enter glob or regexp patterns to be added to SyncIgnore.
-
The .bts file is just a placeholder for the actual file. If you delete the actual file a placeholder with the exact same name + .bts as the extention is placed and is ~ 100 - 200kb in file size.
Or if you mean something else, can you maybe try to explain it a bit more?
See http://forum.bittorrent.com/topic/33718-selective-file-sync/?p=98010
Yes, that's what I said. If you delete a file, it is replaced with a placeholder. It doesn't actually delete the file (from other devices that are syncing that folder). This is confusing, especially if the delete operation is not made interactively by the user in Finder or Windows Explorer, etc.
Deleting a file should delete the file. BTS should not overload the operating system's delete operation with "stop syncing this file". To convert a file or a folder that is currently synced back to a .bts link should be a right click option.
I suspect that apps that access files in an "on demand" synced share like this might make it easy to produce unexpected results. E.g. if I delete a song from iTunes and tell iTunes to move the file to the trash instead of keeping the file, as far as iTunes on that device is concerned the file will be gone (actually replaced with a .bts link) but for all other devices, it will still be either synced or available (as a .bts link).
What I want is "selective sync" (where I can choose which paths or patterns are NOT synced from a dialog, just like Dropbox), and then everything else IS full synced. So if I delete a file, it is removed from all synced devices. If another device adds a new file, it is fully synced as long as it doesn't match an unchecked path or pattern in the selective sync options for the share.
"Selective Sync" might just be a GUI for SyncIgnore, that shows all file paths that are available on remote devices as checked by default. Anything that is unchecked gets added to SyncIgnore.
-
Ah, I see. I have to go to "my devices" preferences and change it in there. Awesome!
Common Identity - Pro Only?
in Sync General Discussion
Posted
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?