Corin

New Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by Corin

  1. So I'm trying to convert our use of Sync to the 2.0 API and noticed the POST folders/ API still creates 1.4 folders.  Is there any way to create a folder the same way the GUI does using the v2 API?


    Alright, never mind.  I found this other post asking basically the same thing (http://forum.bittorrent.com/topic/39699-sync-api-20-add-folder/) that says look here: http://forum.bittorrent.com/topic/38864-announcing-20-api/ for when this might happen.

  2. We've starting migrating from the 1.4 API to the new 2.0 API.  Many things are much better but one simple piece of functionality seems to have disappeared:  the ability to get the version of Sync currently running.  We use get_version from the 1.4 API to do a quick test if the node is online and to report the version running so we can see if all nodes are running the same version.

     

    With the 2.0 API, the closest I can see is the /client/ call but the version field in the response is 0 unless there is a new version available and then it shows the version available not the version running.  How can I get the version of Sync currently running through the 2.0 API?

     

    Thanks,

    Corin

  3. In the config file it is possible to specify the port btsync listens on.  It is also possible to specify the IP and port for the web UI.  However, I have failed to find a way to specify which IP btsync listens on.  

     

    So when running v2.0.120 on linux, if multiple IP addresses are available, how do I configure btsync to use one IP instead of the another?

     

    Thanks.

  4. I've found a way to work around this:

    1. On the node that needs help recalling what was synced, set the download pref to 1 for all files you want it to recall

    2. Touch the files.

     

    Within seconds, Sync suddenly realizes the files are there and starts reporting that it has all pieces.

     

    This works but it gets tedious calling the set_file_prefs API with download=1 for each file.

  5. We have a couple Sync nodes setup using selective sync.  We're running 2.0.120 on all nodes.  One node has all the files and the other nodes have only some of them.  While setting up additional nodes, we accidentally mixed identities between a couple nodes.  That confusion broke the syncing.  Correcting the identities on the nodes did not restore sync functionality.  The selective nodes no longer downloaded files even when the download file pref was set.  Mostly the nodes seemed stalled.  They correctly processed the file pref update but downloading did not happen.

     

    After some time spent searching forums for help, we gave up and deleted all .sync folders on the nodes effectively resetting them.  We then set them up again and re-established the link to the node with all the files.  At that point transferring new files was possible, so the nodes were mostly functional again.  However, Sync does not update the state of the previously synced files.  It does index them, is aware the files exist but always indicates it has zero pieces despite the full files being present.  Update the download pref to 1 doesn't help either.  The logs end up looking like this:

     

    [20150616 09:05:48.056] SF[C24D] [F24B]: Connect files to peer, queue size 2

    [20150616 09:05:48.056] ScheduledTask:ConnectMorePeers invoked:timer reason:UnloadInactiveTorrents - torrent wants connection

    [20150616 09:05:48.056] SF[C24D]: Torrent /vmfs/volumes/datastore/folder1/file1.vmdk state:6 error: meta:1 conns:0 io:0

    [20150616 09:05:48.056] SF[C24D]: Torrent /vmfs/volumes/datastore/folder1/file1-delta.vmdk state:3 error: meta:1 conns:0 io:16

    [20150616 09:05:49.056] SF[C24D]: Will try to find peer for file "/vmfs/volumes/datastore/folder1/file1.vmdk"

    [20150616 09:05:49.056] SF[C24D]: Will try to find peer for file "/vmfs/volumes/datastore/folder1/file1-delta.vmdk"

     

    So far the only way I've found to get the node back into the correct state is to delete the files off the node and set the download flag to 1 so they are downloaded again.  Downloading again is not a viable solution since we have a large number of files to resync and there are bandwidth limitations.  Is there a way to convince a Sync node that it has a file already without re-downloading?

     

    Thanks.

  6. This!  Please.  The lack of sparse file support makes it very difficult to use Sync.  Syncing a sparse file requires tar before syncing and untaring afterward.  The extra complication in the workflow somewhat defeats the purpose of using a tool for syncing instead of just rsync and cron.