andrewb

Thanks @RomanZ I'll give this a go in quiet time (on the weekend). PS: are you also @Roman Z because it is the second member that pops up when I start typing your handle?

I have been running sync 1.x on a Centos 5.11 server for a long time (currently 1.4.111 beta), although my Windows PC and Synology NAS run 2.3.x. I have decided to make the leap to sync 2.x on the Linux box to hopefully address a few syncing issues ('Out of Sync'). Help. Q1: What steps to I need to take to upgrade to linux v2.2.6? Are there any special precautions? Q2: will it preserve my current legacy sync folders? I am happy to stay with Standard folder. My setup has remote folders that use Read Only keys, I need to maintain this. Q3: I understand that packages are now available for Linux [RPM based]. Will this find my sync install (/opt/btsync) and upgrade it? Or, can I only do a manual install?

Thanks, make my purchase choice easy.

Thanks Helen. Is there a another beta thread on this OR a list of issues? I am not afraid of beta code - started using sync at v1.0.116 . However, I am trying to gauge whether the DS215+ is OK to buy for sync or am I better off staying with an older series using AmardaXP / 37x. Basically, I am concerned about the Armada based ones that are available because they only have 256/512M RAM instead of 1G. I have a lot of files syncing and sync is currently using 240M on my Xeon 3050 Linux box and 218M on myCore i3 Windows 10 PC. Any insight is appreciated.

I am buying a Synology 215+ (Annapurna Labs Alpine AL-212) and it will become me btsync end point. I see in this thread that the sync software for Alpine is in testing. Also, on help.getsync.com/customer/portal/articles/1888507 the Alpine/Alpine4k version can be downloaded. Does this mean it has been released and is now supported?

@RomanZ, I have no explanation for it. Rebooting didn't fix it, but after the most recent patch Tuesday updates and restart it cam good again. Crazy stuff. Whatever stuck it, let it go again.

I have been happily using sync 1.4 on multiple machines, but installed 2.0.105 on one lesser Windows 7 machine to test. One thing that is missing is the sync icon in the notification area of the Windows 7 task bar - I found it useful. In the control panel applet for notification icons, sync is listed - but without an icon, I changed it to be "Show Icon and notifications" and get the message "This notification icon is not currently active". I have looked in sync preferences and can't enable this. Help.

Thanks for the clarification. Is there a thread that discusses this issue?

OK then, I guess I'll wait. Just a thought. Does this only effect 2.0 folders or are 1.4 folders also effected when using sync 2.0.x?

I was thinking of installing 2.0 on my Linux box that currently runs 1.411. The readme (I think) of an earlier version had "Read-only folders are not available " as a known issue. The actual text was "Read-only folders are not available between devices added to "My devices" mesh. We are aware of this limitation and going to fix it in future. For now you can just make a separate identity for your backup PC." This put me off installing since a important PC at the other end uses read-only folders. I can't see mention of this in 2.0.93 or the changelog. Can anyone explain this and confirm if it is fixed.

For Linux (and FreeBSD) the webui is disabled by default for all interfaces except loopback (see link in change log - first message of this thread). This is for increased security. Try running ./btsync --webui.listen 0.0.0.0:8888 to return to behaviour of v1.3. You can set up listen in the config file as well. Consider the security implementation of enabling this.

Has there been a change in the compile for btsync v1..4.xx regarding glib23_i386 vs i386? See this thread. I have Centos 5.9 i386 with glibcc 2.5-107. from btsync 1.1.116 to 1.3.94 I have downloaded and installed the i386 compile (btsync_i386-1.3.94.tar.gz) and this worked fine.from btsync 1.4.72 the same i386 compile would not run and gave an error like:symbol lookup error: /usr/local/bin/btsync/btsync: undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageEThanks to @cjvs on the the 'Btsync 1.4.75 (i386) Crash On Readynas Pro' thread I have got running again by using the glibc23 compile for i386 (btsync_glibc23_i386-1.4.75.tar.gz). Which is why I ask why? - was there a change for 1.4.xx and is this the new way?

On the 1.4.75 (i386) Crash On Readynas Pro thread, @cjvs, on 15 Sept 2014 - 05:10 AM, said: This seems to work OK for my Centos 5.9 i386 install. I have glibc-2.5-107 on that machine and have always used the non glibc23 compile of btsync without a problem. Does this mean the glib23 compile is now needed for glibc >= 2.3. It may explain why @fearedbliss has it running fine on Gentoo x86_64 (he has glibc-2.19-r1).

Thanks - would never have thought to change to the glibc 2.3 version. I can confirm that this works for my Centos 5.9 i386 install.

Also same on older Centos 5.9 As per fearedbliss. I have the following info for my i386 install lddtree output (current 1.4 and older 1.3 versions): #ldd btsync-1.3.94 linux-gate.so.1 => (0x003b2000) librt.so.1 => /lib/librt.so.1 (0x007c1000) libdl.so.2 => /lib/libdl.so.2 (0x00ccd000) libm.so.6 => /lib/libm.so.6 (0x0055c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00bd8000) libc.so.6 => /lib/libc.so.6 (0x00a79000) /lib/ld-linux.so.2 (0x00657000)# ldd btsync-1.4.075 linux-gate.so.1 => (0x00605000) librt.so.1 => /lib/librt.so.1 (0x007c1000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x07660000) libdl.so.2 => /lib/libdl.so.2 (0x00ccd000) libm.so.6 => /lib/libm.so.6 (0x0055c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00bd8000) libc.so.6 => /lib/libc.so.6 (0x00a79000) /lib/ld-linux.so.2 (0x00657000)compiler, glibc versions: gcc-4.1.2, glibc-2.5-107uname output: # uname -aLinux nexus.cnf.com.au 2.6.18-348.4.1.el5 #1 SMP Tue Apr 16 16:02:56 EDT 2013 i686 i686 i386 GNU/Linux

Yep, downloads OK now - but not yesterday. I have checked yesterday's download against today's. They have the same SHA1 hash, so nothing has changed with the Sync binary. My Chrome version has not changed either. So, the change is at Google's back end, not in Chrome itself. I guess this is a dead issue now.

If this happens AND you believe it is a false positive AND you don't want to wait then you can recover the download like this: 1. Got to chrome://downloads/ (or choose Downloads from the menu button) 2. find the BTSync-1.3.109.exe (it should be at the top of the list) 3. click on the "Recover malicious file" link below it and then when prompted click on "Hurt me plenty". Edit: I had this happen when I downloaded yesterday. But just checked after posting and Chrome does not report it as malicious any more.

No crashes for 3 days, looks like there was some issue on my system with the 1.3.106 update. I hope the many dump files give developers enough information to solve this - I try again with 1.3.107+.

Since installing Windows build 1.3.106 on June 25th I have had 15 crashes (that's nearly daily) and each time I have been prompted with a request to send a dump file to the developers (which I have). This is new behaviour. I have not seen evidence of sync crashing on my Windows PC since August 2013 (build 1.1.69). Is this a problem with 1.3.106 - I have now reverted to 1.3.105 looking to return sync to some stability

I have 4 large shares like \\SHOWME\download" that fail due to this bug (I think). However, sync.dat currently has the path shown as "path21:\\?\\\SHOWME\download" (21 = path length) - this seems to fit your "\\?\UNC\" format. Can you elaborate further on your comment? How can i edit an existing folder path?

1.1.15 (also 1.1.260) introduces a bug on the Windows platform. Previously working systems now break if folders use a network address instead of a drive letter. This bug can be reproduced by mapping a network address to a drive letter. Then try adding the a folder, first using the network address and then using the mapped drive letter. Thanks to GreatMarko for the tip. This issue may be related to the 1000's of "SyncFilesController: mutex file check failed" entries that now appear in my logs.

The existing 4 folders with the problem are big (20-100G each), so I was reluctant to try that on live data. But, I have now set up a test sync setup for an additional folder. This share (\\SHOWME\download) was already mapped to T: I have now tried to connect with and without mapping: "\\SHOWME\download" fails with "Can't open the destination folder". "T:" works OK. Yes, thanks for the idea.

gia-btsync, I am not familiar with boxcrypt - Is it mapping a virtual drive to Z: or is this a partition on a local disk? I ask because I am syncing to network shares. I am also having this issue since upgrading to 1.1.22. The Windows 7 sync client (Folders tab) shows this error on 4 folders that are located on network shares. 2 other folders located on a local drive are OK. See image below: This setup has existed unchanged through versions 1.0.116, 1.0.134, 1.1.15 and only had an error starting with 1.1.22. Logs on this machine reports "SyncFilesController: mutex file check failed", over 1000 times in a 45min log.This is a log entry I have not seen before in prior logs, so I suspect it might be relevant. Any ideas or input would be welcome.