• Posts

  • Joined

  • Last visited

Everything posted by affinity

  1. Web UI on [Linux] x64 doesn't work for email and link sharing, the qr code seems to work, but nothing happens using "email" or "link"...
  2. 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.
  3. 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.
  4. A fresh install of 1.4.75 on Linux (Debian 7.6) fails to work with web gui. The /workaround/ is to run 1.3.106 first, accept the terms in the web gui, then shutdown 1.3.106 and try 1.4.75 again. No issues with using Firefox on Windows 7 64 bit.... no requirement for IE for me and that's the way I want it.
  5. I resolved the problem by running an old version 1-3-106 ... it seemed to have /adjusted/ local storage in my browser, then I closed the old version and ran the new version okay. So, there is a bug to fix here..... Edit: Okay it wasn't local storage in the browser that need to be /adjusted/ it was data in the ["storage_path"] .sync folder on the server.
  6. 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/", 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/"
  7. Linux 1.3.105 version (x64) ... cannot change properites of a share to not use tracker or dht servers. With the Windows version, properties on same share change okay (and stick).
  8. Thanks RomanZ, better late than never ;-) Much appreciated.
  9. Thanks Mike. Yes, I found that link already, but the downloads are sans the version number in the file name and are not as easily gotten for simple wget. I like wget and one of the main reasons is that it usually keeps the original file date/time where the server supports it.
  10. Windows offered to download 1.3.94 automatically, but I can't find the /normal/ online links that I am used to, such as: Going to the expected link gives a 404 ....: I much prefer direct downloads that I can use wget, with the download containing the version details.
  11. pwgen gets results too quickly,even for the "-s" option ... so it won't be using /dev/random
  12. 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).
  13. Okay, thanks and sorry for posting in the wrong section.
  14. 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 ....
  15. An error occurred during a connection to Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)
  16. Now with 1.1.42 -- but still no https on Linux X64 ..... please bring it back...
  17. 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.....
  18. 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).
  19. 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.
  20. 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/ ...)
  21. Now using 1.1.33 -- same problem, no https on Linux X64 version.
  22. 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)
  23. If you've done "sudo su" already, then why are you repeating sudo for the other commands? You probably want "sudo su -" anyway, to pickup the super user environment properly.
  24. You can download the Windows version here as well: The trouble is that, all your current sync sharers also need to update..... and who knows if or when they will (I'm talking about some of the public secrets that are out there).