denormal

New Members
  • Posts

    5
  • Joined

  • Last visited

Posts posted by denormal

  1. I'd like to second the request for the ability to share an Advanced folder as encrypted. One of the best features of Advanced folders is the ability to revoke access for an identity, which can only be achieved with Standard folders by regenerating folder keys. As this affects all peers it can be painful in large teams.

    In recent BTS clients (at least OSX and Synology), the ability to generate new keys is not present in the UI (there used to be a link to "Update key"). @ArtemPronevskiy - do you know why this removed? I assume the only way to affect this change now is to disconnect a folder and then re-add it (not as elegant a solution).

  2. @GreatMarko - thanks for your quick reply.

    After posting this I did see that thread - however I'm not sure if this applies. According to the web UI there are no speed limits imposed (attached), and I can't see an upload or download limit in /etc/btsync/config.json or /etc/btsync/user_config.json:

    {
        "listening_port" : 0,
        "storage_path" : "/var/lib/btsync/",
        "pid_file" : "/var/run/btsync/btsync.pid",
        "agree_to_EULA": "yes",
    
        "webui" :
        {
            "listen" : "xxxx"
        }
    }

    Or am I looking in the wrong place? Are there build-time defaults that are being enforced (unlikely)?

    The assertion failures have come at times when the web UI is reporting transfers at different rates (handful of KB/s through to MB/s). As reported by @agend07 it doesn't appear to be affecting performance.

    Screen Shot 2016-04-03 at 23.22.05.png

  3. Possibly related, I am also seeing network-related "assert failed" in the logs running on Debian v8.4 (jessie) on amd64:

    assert failed /home/jenkins/slave-root/jenkins-Build-Sync-Manually-309/network.cpp:2738
    

    The difference in line numbers may be related to the different build architectures - the assertion may be being triggered by the same conditions as experienced in the original report.

    Here are the details on the installed package:

    % apt-cache show btsync
    Package: btsync
    Version: 2.3.6-1
    Architecture: amd64
    Maintainer: BitTorrent, Inc. <support@getsync.com>
    Installed-Size: 9894
    Depends: libc6 (>= 2.4)
    Homepage: https://www.getsync.com
    Priority: extra
    Section: net
    Filename: pool/non-free/b/btsync/btsync_2.3.6-1_amd64.deb
    Size: 5191642
    SHA256: e730aa9f30fccdda2cea7679d3f506042e246d7c9514591a7c799dcf22cac129
    SHA1: 6cc9bcd885151596e575f49cbdcb563ab51d4605
    MD5sum: 7d553ca1c7a0757a0531a3140f7232ed
    Description: BitTorrent Sync is a proprietary peer-to-peer file synchronisation tool.
     It can sync files between devices on a local network, or between remote
     devices over the Internet via a modified version of the BitTorrent protocol.
    Description-md5: 76747236cd3fbbff26384c3d342dbba0

    I'm noticing btsync dropping client connections after a short period of file transfer, although this may be related to local configuration and not the result of this assertion failure.