RomanZ

Administrators
  • Posts

    3,588
  • Joined

  • Last visited

Posts posted by RomanZ

  1. @Jay Siquelus Is your Admin account active? Sync won't be able to run with disabled admin account.

    If yes - let's try to SSH to NAS and run Sync manually - it should display some error on why binary does not start. After logging in under admin, run the following command line:

    /usr/local/bittorrentsync/bin/btsync --config /usr/local/bittorrentsync/var/sync.conf

    And let me know the output.

  2. @mzosama I strongly suggest checking exact paths of folders you sync (you can just hover a mouse over folder and Sync will display the path). It is very common mistake that one starts syncing files not to a designated pre-filled folder, but into subfolder. For example, you want to sync C:\Docs\Engineering from PC A to PC B, and you get it synced to C:\Docs\Engineering\Engineering on PC B (which is obviously empty and will require full data re-transfer).

    Also, please take a look at this article, it may help to properly configure folders.

  3. @nuts You'll need to connect to your NAS over SSH protocol, locate the binary and replace it. Here is kind of instruction for you

    1. Connect to your NAS over SSH.
    If you are on windows - you'll need a putty tool. See instruction here.
    If you are on Linux of OS X - just open a terminal window and type "ssh root@<your_nas_ip_or_name>", it'll prompt for password and you are there.

    2. Locate your binary.

    For Asustor it always stays here:

    /volume1/.@plugins/AppCentral/bittorrent-sync/app

    so just change your current dir with cd command.

    3. Replacing binary
    Rename it to something else for beginning:

    mv btsync_arm btsync_arm_old

    then get the new binary there:

    wget https://download-cdn.getsync.com/2.3.7/linux-armhf/BitTorrent-Sync_armhf.tar.gz

    unpack the archive:

    tar zxvf BitTorrent-Sync_armhf.tar.gz

    and finally rename the binary that was in archive to "btsync_arm":
     

    mv btsync btsync_arm

    Try running your Sync and see if it works.

  4. @JSF Docker image with Sync 2.3.7 is now publicly available - JFYI.

    @jpsimmonds I wouldn't call it security reduction. Syno was working just fine with admin allowed till DSM5.2. They are improving their security by disabling admin. Though, we are aware of it and will definitely check the possibility of moving Sync from admin account.

    @David Loke We are working to get back to official store. So, if under "this issue" you  mean the message that Sync is not compatible - no, it is not yet resolved. Although, if you need to get your Sync working on DSM6 you can simply grab Sync package here and manually install it.

  5. Oleg,

    You understand correctly. When syncing data from Android to other platforms, Sync let know the real mtime of a file, not the one assigned by Android. The only exception is when file gets modified on Android - in this case, the mtime assigned by OS becomes true.

    Quote

    If that is the case, I'd like to tell you that about a year ago, I tried to use BT Sync bidirectionally, and even though in the beginning everything seemed to work fine, shortly afterwards, I noticed that it was massively overwriting my files on the PC with ones from the phone, which haven't really changed, but have the later mtime because of the Sync. That indicates that sometimes this database scheme fails, and Sync begins to take those incorrect mdates at face value. I also lost some files on the PC that were newer versions, but were still overwritted by the older version from the mobile device. Fortunately, I have good backup habits, so I didn't lose a lot of data, but still, with pain in my heart, I had to stop using the very useful bidirection Sync capability. I really, really hope all this will get sorted out some time soon, as Sync's functionality is EXACTLY the solution I need for my situation...

    Shouldn't be the problem since 2.2 release for sure (maybe even earlier).

     

  6. @NNois Could you please elaborate on what you mean that folders get disconnected? Do you see them outlined with dashed line (like re.png ) or your list of folders is simply empty? Screenshot would be great.

    1. There is an article describing adding your pre-populated folders. Note deleting extra folder name - important step.

    2. It depends on the problem you encountered. If all your folders are simply gone, we've encountered it in the past and get it fixed starting from 2.3.4. It also could happen if something damages Sync internal files, especially sync.dat. BTW, note, that sync.dat is backed up to sync.dat.old every time it is saved, so you have a small chance to bring back all folders if you rename back sync.dat.old to sync.dat.

    3. See above in p2 :)

  7. Quote

    Perhaps what you meant to say is that BT Sync attempts to set mtime to the OLD value (that of the SOURCE file), but the OS keeps the new mtime -- is that correct?

    Exactly. Your explanation is much more elegant :)

    Quote

    Question: why can't BT Sync simply try to set both creation AND mtime on the target file to their source values? Isn't that the whole point of syncing files between devices in the first place -- making an exact copy of each file, and then propagating any changes based on the mtime value?

    Devs did a whole research on the topic. Some distros were okay to set mtime, some not, some required additional actions like setting creation time. At the end of day we came to conclusion that it is more effective to store real mtime in our DB rather than craft Sync for every distro.

    Quote

    Which Android distros DO support the proper setting of mtime, then? I suspect that it has more to do with the fact that the creation date/time is not being set properly, and hence mtime fails, too. Does that sound correct to you?

    Sorry, we don't have this information anymore. It was really long time ago. Once we've found a solution, we no longer keep track of such differences.

     

     

  8. @aaljr Peers are identified not by IP, but by unique PeerID instead. It is generated once you install Sync and when you change your hardware (it relies on your Volume ID). So it is likely appeared if you reinstalled Sync or used some cloning software which could mess up with volume id.

    Unfortunately, there is no way to get rid of them now, though in future they'll be removed to special section to avoid floating in front of you all the time.

  9. @whoever-reads-this-topic

    The issue seems to only appear when one is using parallel-nested folders (see diagram below) and is totally okay if you use nested folders on one computers that are linked to separate folders on other computer(s). While we are working to get it solved, it is advised not to use parallel-nested folders.

     

    Untitled_presentation_-_Google_Slides.png