trevellyan

Right - the logs are always active but enabling debug logging makes it much more detailed.

Sounds like you're looking at the debug.txt file, which is created when you enable debug logging and removed when you disable it. To see the actual logs, look in sync.log in the same folder.

I stick by what I said here.

@GreatMarko, am I remembering correctly that there's a limit on the number of peers with Sync (I seem to remember 50)?

The simplest thing is probably to select Pause Syncing from the Sync menu, then make your changes, and then un-pause it when you're done. If you think about it, no matter what the rescan interval, there's always a chance that a rescan could occur immediately after you've made a change that you don't want to sync yet, so there is interval that could guarantee the behavior you seek.

The only obvious issue I've had with experimental builds is that they aren't signed. The effect on OS X Mavericks is that I have to confirm a firewall exception every time I run it. Subjectively the performance of the one I'm running also seems a bit lower than the public version, which I attribute to additional diagnostic code being present, but this could be an illusion.

http://help.getsync.com/customer/portal/articles/1627229-guide-to-ui-folder-preferences-

You should find the More options link at the bottom of the Advanced preferences tab.

You don't have to go hunting for the database files. Removing a folder and adding it back to Sync will achieve the same result. The sequence is: for each peer, Copy Read & Write key (or Read Only key), then Disconnect for each peer, Enter a key..., paste the key and select the folderRegarding not seeing the option to overwrite changed files, you will only see that in the folder preferences of a folder for which a peer has Read Only access.

In 1.4.x there's nothing special about the peer that originally created the share vs other peers with read/write access, but there could still be differences between folder contents among read/write peers. Here are some things that come to mind: If you have entries in the IgnoreList that prevent some items from being synced, there could be files on the original peer that never made it to other peers, and vice versa.Ownership and permissions are not synced.Not all extended attributes are synced by default.

Probably worth a try.

Sync needs write access to synced folders because it creates a hidden sub-folder to store the ID, ignore list and archive. You could argue about whether this is a good thing, but it's the way it currently works.

There's no way to do that in 1.4.x.

You might need to remove the folder and add it again using the RO key.

The way I understand it, in your scenario B can share a read-only link or the read-only key with anyone they like.

Did you send your friend a read-only link or a read-write link? If it was read-write, then you can ask him to send you either a link or the full key. Otherwise, you'll need to share the folder again and generate a new link for your friend. Sync doesn't know that you're the original sender, it just knows that anyone trying to use the link requires approval, and unfortunately you're unable to provide it. The way links work (roughly) is that they provide enough information for a client to request authorization for a specific share. Once approved, the client is then able to obtain the full key for the share, which is what is actually needed to participate. Unless your friend has read-write access, between you there isn't enough information for you to recover the original read-write key (by design). http://help.getsync.com/customer/portal/articles/1630195-links-vs-keys http://help.getsync.com/customer/portal/articles/1628463-link-structure-and-flow

It's supposed to work as a rename in recent versions of Sync, and I've seen renames appear in my history, but I've also seen reports in the forum of renames being treated as a delete and an add.

1. Correct 2. Potentially, assuming their network links are not already saturated. 3. One way this can happen is if someone changes the contents of a folder for which they only have read-only access. If this is the issue, it will go away if they check the "Overwrite changed files" checkbox for that folder.

You need to read about setting up shares and datasets in the FreeNAS documentation. Common practice with FreeNAS plugins is to set up a dataset to add storage to the jail and tell the plugin to use that storage for its data. In your case it sounds like you'll also want to create a share using the same dataset.

I would expect any application that uses database-style storage (iTunes, iPhoto etc) to get upset if a sync occurs while that program is open. If that's what you're seeing, I would expect the solution to be to only have iTunes open on one machine at a time.

When you add a folder to Sync it creates a hidden sub-folder to store deleted files and other data. You probably don't have write access to your Time Machine backups folder, because OS X wants to prevent you from accidentally making destructive changes. You could change the ownership of your Time Machine backups folder, but I wouldn't recommend it. The way Time Machine keeps the storage requirements of your backups under control is by using hard links to avoid storing multiple copies of everything. As far as I know, Sync isn't going to recognize that, and it will try to send a full copy of every new backup - literally a full copy of your entire system for every Time Machine backup. Unless you have an amazingly fast internet connection, it simply isn't going to work. If you read this article and mentally replace each occurrence of "CrashPlan" with "Sync", you'll get the idea. If you want offsite backup, I think you're better off using something designed for offsite backup, e.g. BackBlaze (that's my affiliate link), CrashPlan or Arq. Of these solutions, I like BackBlaze for its simplicity, CrashPlan for its feature set, and Arq for its independence. Arq is the solution that most closely resembles Time Machine in its versioning scheme, but you need a bit more knowledge to set it up. Mods, somehow this post went up twice. Please remove the previous version.

When you add a folder to Sync it creates a hidden sub-folder to store deleted files and other data. You probably don't have write access to your Time Machine backups folder, because OS X wants to prevent you from accidentally making destructive changes. You could change the ownership of your Time Machine backups folder, but I wouldn't recommend it. The way Time Machine keeps the storage requirements of your backups under control is by using hard links, which allow a file to appear in multiple folders even though it's only stored once. As far as I know, Sync isn't going to recognize that, and it will try to send a full copy of every new backup - literally a full copy of your entire system. Unless you have an amazingly fast internet connection and absurdly cheap cloud storage, it simply isn't going to work. If you want offsite backup, I think you're better off using something designed for offsite backup, e.g. BackBlaze (that's my affiliate link), CrashPlan or Arq. Of these solutions, I like BackBlaze for its simplicity, CrashPlan for its feature set, and Arq

I think that's likely to end badly. For example, Sync stores it's data in a sub-folder of ~/Library/Application Support.

In your scenario, if A and B were online together and had time to sync B's changes to A, then A will be able to deliver those changes to C. Many users of Sync have an always-on device that uses read-only keys like your A to serve as a cloud replacement, so that other devices always have a peer to sync with. The read-only designation refers to the fact that changes made to the contents of the synced folder on A will not propagate to any other peer.

You might be able to achieve what you want using the IgnoreList.