• Content Count

  • Joined

  • Last visited

  • Days Won


About fastfwd

  • Rank
  1. Ok, I'll go first... 1.4.91 still has some little issues, but btsync's CPU usage on my Linux system, which used to be a steady 7-10%, is now practically zero while it's idle. Thanks! I'm running 1.4.91 on one Win7/64 machine, 1.4.91-i386-glibc2.3 on a Debian Etch box, 1.4.83 on two more Win7/64 machines (soon to be upgraded to 1.4.91), and 1.3.109 on a WinXP machine. All the machines seem to be playing nicely with each other, and I haven't seen any new problems.
  2. Thank you for the explanation. How will this issue be addressed? Will future i386 versions be built so that they will run on those older systems, or will we have to continue running the glibc23 versions, or will there be yet another variation -- i386 built with an older toolchain -- or something else?
  3. On this system, BTSync-i386 version 1.4.75 crashes immediately on startup, exactly as version 1.4.72 does: symbol lookup error: /usr/local/bin/btsync/btsync: undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageEThe OS is what Netgear calls RAIDiator 4.2.26; it's Debian Etch (Debian 4.0) running on a ReadyNAS Pro. Kernel is version My earlier error report for 1.4.72 is here:
  4. When starting BTSync 1.4.72 on a Debian box which had previously been running version 1.3.106 with no errors, I get: symbol lookup error: /usr/local/bin/btsync/btsync: undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageEPerhaps there's some library that's not being properly linked?
  6. Oh, I see. I misread "the Linux machine had a full disk" as a symptom of the problem rather than the cause of it.
  7. If that is true, the developers should have re-posted the 1.1.70 build with a version number greater than 1.1.78, so that 1.1.78 installations would see a "new" version and upgrade to it.
  8. 1.1.78 was being served from for a day or two, then it was pulled down and replaced by 1.1.70. Looks like 1.1.78 was built on 13 September: