RomanZ

knireis, It looks like the btsync on first machine is up and running (as you see it as connected device on another), so this looks to be an issue with WebUI only. Could you please try to access to webUI from a different browser (or just clean up all cookies)? michellelynngill, The advise was going initiallty to Roza, who seems to have only 1 mac and 1 linux machine. In such setup it always better to ignore xattrs on Mac machine. If we do so - both PCs will show as synced when they finished transfer. If we ignore xattrs on Linux machine, when sync complete Mac will always show that it wants to upload some data to Linux (which equals sum of all xattrs not synced). As you still want to sync xattrs between your Macs - of course, you have to modify ignore list on Linux machine (we recommend syncignore to be the same on all PCs, but in your case that will bring to a loss of some functionality).

AzaK The issue happens due to peculiarities of Windows API working with alt streams and implementation of HFS+ for Windows. BTSync has to store xattrs received from Mac machines in alt streams. Alternate streams on Windows are accessed with the same API as the rest of files, but application also adds ":<streamname>" line to access some particular name. So, to access to AltStream "ZoneIdentifier" of freshly downloaded installer, application opens a file "C:\Users\<username>\Downloads\MyInstaller.msi:ZoneIdentifier". Actually, HFS+ (in contrast to NTFS, FAT and other MS file systems) supports ":" in the file names and paths. So, any developer who wants to implement HFS+ for windows has to choose: either support WinAPI to access xattrs in the way as Windows does, OR - support colon symbol in filename. Paragon Software decided to support colon in the name of a file. To summarize - this is an issue of a HFS+ implementation for windows, rather then BTSync bug.

michellelynngill, If you have 3 peers, 2 Macs and 1 Linux - Macs will sync xattrs successfully. But they will fail to sync their xattrs to Linux machine. There is a certain limitation on Linux PCs how xattrs should be named, so Mac names for xattrs does not conform Linux demands. Windows should accept Mac's xattrs with no issues, if files are hosted on NTFS partitions.

Roza, BTSync can't sync mac's xattrs to your linux machines. Add them to .SyncIgnore on your Mac machine.

Blacky, It should work, but you should keep in mind few things: 1. It must be the same platform, cross-platform settings copy won't work. 2. Your paths must be completely same on new PC. 3. The old instance of BTSync should never run, as your computer ID is stored in settings and must be unique.

suntear, Lujo, The BTSync local discovery mechanism changed significantly between 1.2 and 1.3. In your case it looks like your Windows machines did not subscribe for multicast to appropriate NIC. I could advise to disable all the rest of virtual adapters as a test to see if it helps resolving your issue.

jhonan, We are aware of the issue and will fix it soon. Thanks for bringing our attention.

kaan, Thanks for reporting. We'll fix it, try re-downloading in 10-15 mins.

JSommer, Could you please: 1) Make sure that BTSync updated to 1.3.87 on all of your peers 2) re-add sync folders, containing umlaute characters 3) see if the issue is gone I suspect that your DBs now contain invalid characters, that's why you still see .conflict folders. Thanks!

vlmath, Thanks for letting us know. We'll fix it.

Hi all, The build 1.3.87 for desktop platforms is available now. Change list - Fixed app crashes Here is previous build change list.

Nefarious, Please see the build with the fix here.

Hi all, The build 1.3.86 for desktop platforms is available now. Change list - fixed issue with transfer speed wrong calculation - fixed issue with handle leak for Linux and Linux-based platforms - fixed issue with unicode characters in filenames on Mac platforms - fixed issue with limiting traffic for LANs - fixed app crashes - added columns configuration in Devices tab Previous change list.

klausemann, To make sure that I understand you correctly: - You have 2 NASes in 2 locations. - There is a folder that you want to sync between 2 NASes. - Also, every location has computers that wants to sync sub-folders of the folder synced between NASes. - computers sync sub-folders successfully, while NASes does not want to sync changes, only new files. Is this correct?

smeerbartje, Every file is split to "Pieces" when transferred. To ensure data integrity, BTSync hashes every piece of file (and then later hashes all hashes to get the checksum for the whole file). Piece hash failed means that the hash on the local peer is different from what he actually got from remote peer. It could happen if the file was changed by some means and BTSync did not detect it (for example, file changed while its size and mtime stays the same - in this case BTSync won't re-hash it). Can you share your experience? Is there something not working when you see the error?

Photoniac, The first error means "Connection time out", i.e. your BTSync did not manage to connect to tracker server over TCP, as tracker did not respond. I'm not sure about the second error, it will take some time to check what does it mean. Second error means that BTSync failed to establish direct connection to another peer. Could you please share your symptoms? What is not working?

Right-click BTSync icon in the system tray on Windows machine, choose Send Feedback. Please put the reference to forum topic. When you get the auto-response from our ticket system, you can reply with attached logs.

Ruimg, Couple of things to check. 1. Please check if your HOX2 does not have the files that are in the log. It might happen that your HOX and HOX2 have similar sets of files. 2. How did you create HOX and HOX2 folders? If you create one, then add it to BTSync then copy it - it will bring some service data within, to be precise - .SyncID file which is intended to distinguish one folder from another.

moored99, Sorry, cannot give you ETA now.

Jero, BTSync does not support multiple config files. However, instead of modifying existing config file - you can build it from scratch with your deployment script every time when you want to apply some change.

mongo, Does it ticket if you set it, exit app, do NOT reboot phone and start the app again?

On Linux - just replace the binary. Here is the link to 1.3.80.

Suntear, When auto-sleep is ON and there is no actual transfers ongoing, BTSync unloads the sync engine. When the auto-sleep period expires, BTSync loads the code, and checks if there is anything necessary to sync. If it is - it syncs. Once the sync is complete and no events happening for around 1-2 minutes, BTSync again unloads the core for another sleep period. Of course, all of other peers will see that the Android device is gone when engine is unloaded.

Oneclick, According to logs you suffer the handle leak issue, just like in this topic. We are preparing a fix for the issue, for now as a workaround you can roll back your btsync to 1.3.77.

SpencerH, What happens to the btsync process? Is it still running? WebUI accessible?