affinity

Members
  • Posts

    69
  • Joined

  • Last visited

Posts posted by affinity

  1. I'm finding that on Debian 7.6 Linux that a sync might start at around 20 minutes after adding the secrets, then it will not take advantage of having the data on the LAN when available -- it sometimes ramps up to high speed via the LAN, but still drops back to remote links with transfers dropping down to very low levels for no good reason at all that I can see.  Eventually the data, in my case about 25GB, would be transferred in about 2 hours.  I've done this with multiple machines, same results, I've even given the local hosts in the preferences to use for the machines still yet to sync up.

  2. There seems to be many more problems with the Linux version of 1.4.75 -- I added a folder to sync, the remote folder -- actually available on the LAN on a Windows box (has over 25GB) ... as well as other remote locations, but the newly added folder on the Linux box says it is synced, but no files have been added. :(

     

    It looks like I'm going to have to revert to an older version at this stage.

     

    Edit: stopped and restarted the Windows client, now the Linux client is receiving...

     

    Edit: this is so frustrating, it says it is receiving, but it is not taking advantage of the LAN copy and it seems to be stopped even though it says it is still going (extremely slow speed).  The LAN has kicked in now, getting some reasonable speed.

  3. Hi,

     

    I've got a Debian 6.0.10 (squeeze) Xenserver running BTSync 1.4.75 without any problems, but when I copy the same binary and conf file to a newer Debian 7.6 (wheezy) machine, it won't work properly.

     

    Old Machine:

    # uname -a
    Linux server-name-1 2.6.32-5-xen-amd64 #1 SMP Tue May 13 18:41:58 UTC 2014 x86_64 GNU/Linux

     

    # ldd --version
    ldd (Debian EGLIBC 2.11.3-4) 2.11.3

     

    New Machine:

    # uname -a
    Linux server-name-2 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
     

    # ldd --version
    ldd (Debian EGLIBC 2.13-38+deb7u4) 2.13
     

     

    The conf files are identical for both machines, excepting the device name; all paths are the same, with the exact same permissions.

     

    If I change the directory for the pid file to a directory that does not exist, then btsync won't start, so I know it is reading the right conf file.

     

    This is the binary I am using on both machines:

    btsync_x64-1.4.75.tar.gz

     

    On the /bad/ machine, I login in the browser, then I get a welcome screen asking to create a user with password and confirmation.  On the /good/ machine, I don't see the welcome screen.

     

    What am I missing?

     

    Edit: Adding diff from sample dump config file....

     

    $ diff btsync-1-4-75--sample-config btsync.conf
    10a11
    >    "pid_file" : "/home/myusername/btsync.pid",
    13c14,15
    <   "use_upnp" : true,
    ---
    > //"use_upnp" : true,
    >   "use_upnp" : false,
    16,17c18,19
    <   "download_limit" : 0,
    <   "upload_limit" : 0,
    ---
    >   "download_limit" : 0,
    >   "upload_limit" : 0,
    32,33c34,35
    < //  ,"login" : "admin"
    < //  ,"password" : "password"
    ---
    >     ,"login" : "admin"
    >     ,"password" : "mylongpasswordwithaspaceafterthissection more"
    35c37
    < //  ,allow_empty_password" : false // Defaults to true
    ---
    >     ,"allow_empty_password" : false // Defaults to true
    42c44,45
    < //  ,"directory_root" : "/home/user/MySharedFolders/"
    ---
    >     ,"directory_root" : "/home/myusername/MySharedFolders/"
    > //  ,"directory_root" : "/MySharedFolders/"
     

  4. TheDurtch  ... why so complicated?

     

    "base64 -w0"

    - will give you a string of chars without new lines, so no mucking around with sed to join and adjust lines.

     

    base64 gives you a couple of extra characters, the "+" and "/" symbols,  why exclude them?

     

    Here's another variation for you:

    head -c $((256/4*3)) /dev/random|base64 -w0

     

    [Mac users can omit -w0 or use -b0 instead  .... don't ask me why it is different, BSD might be the same as for Mac]

     

    You can change 256 to any number you like.  It also won't matter if the base64 is padded with "=" signs at the end for the secret (the above won't pad anyway).  If the chosen number is perfectly divisible by 4, then you'll get the exact same number of characters back (which is a bit different to your version) -- and you won't be getting too many random characters to work with (just enough to achieve the result).

  5. Yes, it has indeed been a while since a new build, but the team are hard at work on Sync 1.2, which will include a whole host of performance improvements over 1.1.x, including, most notably improved transfer speed (in some cases twice that of 1.1.x builds) and lower memory usage (in some cases half that of 1.1.x builds), and there will also be improvements to .SyncIgnore and error handling.... essentially, the focus is on improving the core of Sync first, features will come later.... so watch this space! :)

    I understand, but it would be good to get an update in the first post..... 1.1.82 is the latest, not 1.1.70 .... :(

  6. I'm seeing loads of errors like this one:

    "Failed to download xxxx\xxxx.jpg - CloseHandles: Cannot create a file when that file already exists."

    Don't know if this is related to the crashes at all, probably not as there are too many of these messages. Don't know if these messages were there before or not as I never went looking at history for problems.....

  7. For the first time in BTSync history, I today saw lots of crashes with the latest 1.1.40 version -- no such crashes with earlier versions, ever. Windows only, Debian running standalone 1.1.40 is not giving any problems, aside from the inability to use https which I keep reporting for the more recent versions ;)

    The built-in dump reporting has failed too.

    Edit: I might add that the Linux sync only has a very small set of local files which are not shared externally -- just b/w my Windows and Linux machines for testing / proving of both versions, so, in short it isn't working as hard on Linux as it is on Windows which has more syncs (most from external sources).

  8. Definitely also prefer .SyncArchive over SyncArchive too -- better still, name the folders ourselves...

    Actually I would also prefer to see the .SyncArchive data remain there indefinitely AND be under my own control, not that of ALL users of a common Sync that is world writeable by anyone with the secret.

    The "sync_trash_ttl" -- that needs a default, 30 days is fine, it needs 0 for no trash and say 99999 for never clear or something like that.

  9. Using http://syncapp.bitto...4-1.1.27.tar.gz

    GUI via https isn't working :(

    http works, but I want https

    The 1.0.34 version runs https without any problems....

    An error occurred during a connection to nnn.nnn.nnn.nnn:8888.

    SSL received a record that exceeded the maximum permissible length.

    (Error code: ssl_error_rx_record_too_long)

    Now using 1.1.40 -- same problem, no https on Linux X64 version, please fix this!

    I do not want http access, I want only https -- it used to be possible (without resorting to tunnel /tricks/ ...)