trevellyan

Members
  • Posts

    142
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by trevellyan

  1. 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.

  2. 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.

  3. 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:

    1. for each peer, Copy Read & Write key (or Read Only key), then Disconnect
    2. for each peer, Enter a key..., paste the key and select the folder

    Regarding 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.

  4. 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.
  5. 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

  6. 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.

  7. 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

  8. 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.