RomanZ

@mrmachine No, unfortunately Sync does not support includes / excludes in IgnoreList or StreamsList at the moment.

@Sam BTSync won't re-create hard links. It will create files.

@Brilliantsam It might be app crash. Could you please ask your users to check ~/Library/Logs/DiagnosticReports and see if there are any recent crash reports with "BitTorrent Sync" text in report name?

@Iminent In Sync 1.4 you can try to share read-only folders to devices consuming data. So, the deletion won't actually do anything. Alternatively, you can check the Sync 2.0 and on-demand folders.

@fedele.mantuano I suggest checking if the user running Sync on your RPI has enough permissions to write data to sync folder as well as to storage folder.

@markymark77 Not exactly. Sync is invented more for small-scale use usage rather than broadcasting data to the whole world. And the auto-update situation isn't something like a bug. We push only the most stable and reliable versions to auto-update. Community members that are willing to get the latest are always welcome on forums or can use direct download links.

@drego85 What does the folder show next to out of sync? Does it believe that other peer is offline? Couple of screenshots would be great.

@vasaka The forum is dedicated to BitTorrent Sync product, not to the data synchronization in general. SyncThing was mentioned on the forum, and that's enough to indicate that alternative exists. All the rest of information can be found on SyncThing forum and website. Please feel free to PM me if you want to continue discussion on topics moderation.

@calvyb Oh, right. Sync logging also can awake your NAS. Please disable your logs by putting "0000" (four zeros) to debug.txt which stays in storage folder. I'll update topic starter.

@carloxp I've sent it to mailbox your forum account registered to on Friday Feb 13. I also duplicated to your forum PM today. @Petrenko_denis Yep, you need to rename btsync to sync-core and replace old one. You should not start it manually - use commands supplied with your package ("service btsync start" IIRC). In general, after replacing it should work exactly as before and listen same ports and NICs. @calvyb The most common thing to check on Linux machine is permissions. Check what is the user running your Sync and if it has enough permissions to read and write data to: a) folders you want to Sync your storage folder (.sync by default, though can be adjusted in config) @jwk2801 Yep, I need debug logs to find out what happens there. ReFS could be an issue, although Sync rescans all the folders for changes every 10 minutes by default so it should detect changes even if ReFS driver does not send any notificaitons.

Yep, it looks to relate to mobile - at least I've got described behavior for Android in my lab. Thanks for the feedback!

@AetherMichael Okay, so it's not about comparing hashes and checking file integrity but more about manual control of sync direction. I'll adjust topic name.

@herbert, @carloxp Please check your mailboxes - I've sent you a build. @Petrenko_denis Looks like you are using some package. Just run "ps aux | grep sync" to find out where sync binary is actually started. It could happen that executable name actually differs from default "btsync"

@kewi Thanks for the log. I've opened a support ticket for you - we'll find out what happened.

@calvyb Note, that if there are some nodes online that update files or request some data from your NAS - this is going to awake HDD. Just as a test - make sure that no other nodes are online and see if your NAS sleeps.

@drego85 2.0 should not show anything if status is "okay". So it is not a bug. You can click the "x of y peers" and see extended per-peer status there.

@b0rman Thanks for the logs, I'll let your know analysis results.

@Petrenko_denis Just sent it to your mailbox.

@b0rman Unfortunately this cannot be changed, it's not simply limited by some variable but this is more core limitation. We are aware of it and plan to improve in future. Although, if you got average file size ~25Kb you should get your speed around 1.2 Mb/Sec, so the 50..150 Kb/sec is way too slow! Could you please send me some debug logs of your regular sync of these small files?

@b0rman What kind of files do you transfer? Sync has a certain limitation on amount of files it processes per second, so if you've got a bunch of tiny files - they can affect transfer speed significantly (though should not introduce saw-shaped traffic).

@calvyb Your Dlink NAS has ARM CPU, so just grab appropriate binary and replace it (Sync should be shut down of course). Note that you'll need to set certain preferences to make HDD sleeping (see topic starter for details). @colinabroad Keep me updated. And as peer #3 usually introduces some issues - just in case - keep debug logs on

@scotepi Sync also does syncs only parts of file that change. However, there is not any advanced algorithms that find the changed parts and non-changed. Sync simply splits file to pieces and calcs the hash of each piece. If the file was changed for a couple of bytes at the very beginning so the rest of file will be shifted, Sync will consider such file as completely new - and resync it fully. After studying shortly on how JPEG stores EXIF information I found out that it can be inserted virtually anywhere in the file. So I strongly suspect that in your case Sync considered way too much changes in your files - and wants to re-sync large amounts of data.

@LucasAzazer Not at the moment. Yeah, we already got such a feature request in the past - and will consider implementing it in future.

@mrmachine Many of MacOS streams are computer-specific and are not valid on other computers. The FinderInfo is a good example - if synced, every Mac is going to fix it is only valid for one computer - which forces Sync to transfer it again and again. You still can allow synchronization of all streams by putting "*" into SyncStreams, though it is not recommended. For the setting a global list of Streams - it sounds like a feature request. Mention it here so it won't be lost.

@rstarkov, @Moe Never say never . Your feature request is heard and filed. When planning new release we usually take several from feature requests.