RomanZ

shawnv, Can you share the log?

Suntear, Do you have auto-sleep option ON on your Android device? If yes - could you please try to turn it off to see if this is a root cause?

Wck, It depends on your office security policy. It is very common policy that wifi is less strict network (and has access to less amount of resources) while wired network considered to be safe, has more limitations - and full access to internal resources.

thelinuxfr, Thanks, i've got debugs. I'll let you know analysis results. thelinuxfr, There some strange records in your log. - "mutex check failed" indicates that the SyncID file was not found in the directory "/srv/backups/test2" - or BTSync failed to get access there. Please make sure that you did not delete this file and the user running btsync has enough permissions to read and write to the folder. - "Changing IP address from 192.168.8.250 to 0.0.0.0" indicates that you no longer has network. Obviously, btsync won't be able to sync when net is down.

noiime, Thanks for the dump, I'll share the analysis results. Roman.

You can call "Get Folder Peers", it will let you know the timestamp of the last sync. Also, it will show you the upload and download values, which represent the necessary amount of data to be transferred. If both are zero - no sync is going now and folders are synced.

mneureuter, It is not implemented. Thanks for the idea - I suggest also putting it to Wishlist.

all, Thanks for reporting. Let me see how it can be fixed.

Could you please elaborate? Do you mean that BTSync should inform other peers that this file is open and should not be touched, or some messaging system between BTSync instances?

mneureuter, It hardly depends on the application which actually reads / writes the file. For example, notepad++ does not keep the file open and detects the fact that it is changed on the disk by someone else. But in general, the file delivered from one peer to another only whole, i.e. BTSync won't merge the changes you are doing on the same file. At the end of day the same file would be on both peers, most likely the version of the peer which was saved last.

They survive mixed environments, but can't be synced to Linux machines (there is a limitation on Linux PCs on how xattrs should be named, and Mac xattrs does not satisfy this naming convention). On Windows - it depends on file system as they are stored in alternate streams. Alt streams on windows, xattrs on ioses. Separately. They are treated as files inside files. In your sample xattrs should be synced separately without syncing or re-hashing of your 1Gb files. xattrs / alt streams are synced on a whitelist (you can find the list where you saw the announcement). So if something falls behind the list - it won't be synced.

cz2000, Could you please take a look at this post and try my suggestion there? The test would indicate if the actual direct connection to the tracker server is working or not.

It worked, thanks. I've got the dumps and will inform you about analysis results.

thelinuxfr, Yes. First of all - try starting btsync with --nodaemon switch and see what will it say to the console. Also,m make sure that your terminal has ulimit -c unlimited and make a core dump of the process when it starts consuming 100% CPU time and not responsive.

ILay, Why do you need to move them to PC? You can connect your ExtSD to PC and move files on the SD card. Moving files on a single partition is rather quick, as no actual move is done, just file table adjusted.

Himselfv, Are you getting the single filename longer than allowed by your OS \ FS? Could you please share which OS and filesystem do you use?

visnumber, Thanks for reporting. We've managed to reproduce issue in lab and will fix it in one of future releases.

Looking forward for the logs.

mongo, it looks like your BTSync can't save the settings. Are other settings saved successfully?

deet, BTSync requires glibc 2.4 and newer. If new DSM OS has it - you can get your BTSync up and running.

Dantounet, Could you please elaborate which issue do you have on 1.3.80? Bad share ID or bad message len?

Stanha, Could you please provide core dumps again? You can send the links to PM.

myuchan, Thanks for the logs, we'll come back to you after analysis.

tuxpoldo, Thanks for reporting, we'll consider adjusting it in future versions. As a workaround you can adjust settings.dat and sync.dat file permissions manually.

KindOne, Could you please make couple of core dumps of btsync process when it starts hanging? Thanks!