trevellyan

Members
 View Profile  See their activity

  • Posts

    142

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Everything posted by trevellyan

  1. trevellyan
    Anyone with a valid key for a folder can share that key with someone else and thus grant the same (or less) access they have to that other person. It's been this way since I began using Sync, which was late 1.2.x if I remember correctly.
  2. trevellyan
    I don't see sticking with 1.3 as an option. Recent releases of 1.4.x have fixed bugs that would likely result in data loss in earlier versions (see the release notes for details). However, I agree with @sfmcnally regarding the upgrade process from 1.3.x to 1.4.x not being smooth. For me the best outcome was from a completely clean install of 1.4.x, after removing all trace of 1.3.x from all peers. It's a drag, but I think it's worth it.
  3. trevellyan
    The folder can exist on the local machine, but it shouldn't already be set up in Sync.
  4. trevellyan
    I see nothing obviously wrong with the process you described, but it doesn't match your screenshot. The dialog you posted is for updating a key for an existing folder. Have you tried removing the folder from Sync on the PC, then using the Enter a key dialog to start over?
  5. trevellyan
    I would not choose to sync an entire drive. In my view, synchronization is not backup. I sync specific folders for which near-real-time synchronization is useful. I use backup solutions for backups of entire drives. In either case, it often make sense for a NAS device to be involved. One reason I started using Sync was for the flexibility of being able to sync specific folders to specific devices, without having to reorganize those folders and without having to make do with all-or-nothing on every device. As you point out, these advantages are lost when syncing an entire drive, not to mention the performance implications. If the drive happens to be where things like Windows user folders are stores, there are technical reasons not to sync the entire drive (or even entire user folders), related to where Sync stores it's internal data. But from the way you describe your setup, it doesn't sound like that's what you're doing. Nested folders are possible if all are shared read/write with all devices.
  6. trevellyan
    Are you by any chance attempting to use nested folders, i.e. trying to sync a folder that's inside another synced folder? Sync only permits that when the folders are read/write.
  7. trevellyan
    Start here: http://help.getsync.com/customer/portal/articles/1672241-guide-to-linux?b_id=3895
  8. trevellyan
    Different versions might cause a problem. I'm still curious to know exactly how Sync responds when it refuses to accept the read-only key, since this is something I haven't seen.
  9. trevellyan
    Are you using the latest version? Is the destination folder empty? I think some versions won't let you use a read-only key if the destination isn't empty. Exactly how does Sync respond when you enter the read-only key?
  10. trevellyan
    In the web UI, when you hover your mouse over a folder, you should see a Share button in the right column. Next to that button is a button with three dots in a vertical line. Click the button with three dots to pop up a menu, and select the Disconnect option (might be named differently in 1.4.76).
  11. trevellyan
    If the NAS is the device that you want to have read-write access, then the simplest thing would be to set the folder up on the NAS first. From there, you will be able to get a read-only key to use on another device.
  12. trevellyan
    When I had a read-only peer out of sync, the logs revealed that the peer was identifying a file as locally changed and therefore refusing to sync it. The workaround that has been reliable for me is to check the "Overwrite any changed files" option on read-only shares. Obviously this workaround is only usable where you don't want to keep local changes, as with a cloud replacement style node. Of course, this doesn't explain the erroneous detection of a change on a peer that nobody touches...
  13. trevellyan
    I don't understand this, but maybe I'm missing something. The way I see it, the phone (or any peer) will only spend as long as it needs to get any new content shared with at least one peer. While the phone is busy doing that, all other peers will be sharing with each other. If we assume the phone's connection is the slowest, all other peers will be done as soon as the phone is done. Remember, Sync is full duplex, i.e. data flows in both directions at once on each peer.
  14. trevellyan
    It seems to me that you're holding some misconceptions about how Sync works. First of all, key expiry and confirmation are only relevant to the first use on an additional device. Once set up on a device, a key never expires, nor does it require further confirmation. Second, the idea of having multiple devices using the same key is that they all exchange information with each other. If a key for your phone is shared with multiple other devices, it won't take any longer for the phone to deliver changes, because the other devices can communicate those changes among themselves. It might be a good idea to start by reading all the articles under Getting Started With Sync and Common Questions at http://help.getsync.com/.
  15. trevellyan
    Sync works with keys, so all you have to do is set up each key/folder combination on the server and the offsite computer. You don't have to tell the iPhone or either server anything specific about any other device, because they find each other using the keys.
  16. trevellyan
    Is there a reason you don't want to share the individual folders with the off-site computer?
  17. trevellyan
    I think you can do nested folders if all the keys are read-write keys.
  18. trevellyan
    Yes, you have to start Sync using a config file. This won't affect other nodes - synchronization uses keys, not the gui password.
  19. trevellyan
    Make sure you're not actually using uppercase for the GUI part.
  20. trevellyan
    Sure, I'm just not really interested in syncing those attributes, but I'm sure some people find it useful and I'm glad Sync can do it.
  21. trevellyan
    Interesting. Mostly I sync lots of small files, and for those my LAN rates tend to hover around 1MB/s with Sync. When I sync large files, I easily get into double digit MB/s. Most of the time at least one peer is on WiFi (802.11n). They're all Macs except for the obligatory always-on Linux box. All settings are default except folder_rescan_interval and UPnP port mapping. I'm comparing with other automatic synchronization applications, not direct transfer, FTP or similar. Most worked OK with large files, but they all bogged down when I hit them with thousands of small files all at once. Some were orders of magnitude slower than Sync in that scenario. I would regard that as by design, Sync playing nicely with higher priority traffic. I believe the protocol is designed to do that. In fact, at one point I was limiting upstream bandwidth for fear of saturating my connection, but I stopped doing so and it never seems to be a problem.
  22. trevellyan
    Are you syncing mostly large files, or mostly small files? The only time I see performance far below available bandwidth is with lots of small files, and it's still much better than every alternative I've tried.
  23. trevellyan
    Maybe you can find what you're looking for using the API.
  24. trevellyan
    Yes, it's called TextEdit.
  25. trevellyan
    Yup - http://forum.bittorrent.com/topic/18036-extended-attributes/