RomanZ

@mike20021969 Ok, thanks for the feedback, we'll take care of it.

@ckp, BTSync won't sync files if hash of the file is the same - even if mtime of the file has changed.

@playontv, We are looking for the solution or a workaround and implement it once it is found.

@hungarianhc, Well, AFAIK FreeBSD will automatically drop the core dump file to the same folder where the binary runs. No special settings required. @merlinuwe, For convenience, I've organized our question-answer session below for not yet addressed / answered issues. I tried to reproduce the issue in the lab - and failed, the port does not change. There is a logic in BTSync which changes the port if it is occupied (say, previous instance of BTSync is running and bound to the port). So - how do you upgrade? I suggests checking if the port is available when you run new Sync. No, we did not reproduce it in our lab. There is a known issue with the speed in certain cases. It is very complex to debug, as it requires a special set of debugging information. We are now preparing a debugging tool for speed issues, so please follow this topic as I'll update it once tool is ready. As a quick solution I may advise turning off "low_disk_priority" advanced option as it helped people in couple of cases. @mike20021969Thanks, we'll consider your proposal for next release. However, IIRC - we don't put our icon to quick launch, do we?As for binary replacement - it should work. When you upgrade, all necessary changes to the DB and config files are done on first actual BTSync launch, not during the upgrade itself.

@zkyevolved, There are a lot of users on forum reported to run BTSync on RPI. Couple of peculiarities you should be aware regarding BTSync on RPI: 1) CPU power. BTSync uses CPU extensively for 2 main things: hash data (when new files are added, new files are coming from network, etc), and data encryption / decryption (especially if peer is an encrypted node). As RPI is a cheap and low-power platform, you should not expect an overwhelming performance, 2) Power issues. Note, that RPI is powered via USB and consumes no more than 500mA (as according to USB 2.0 specs). The external drive you connect is strongly advised to have it's own power supply or you can get a whole bunch of weird and strange issues with it. 3) Permissions. Be sure that you set up your permissions on Linux clearly and simple or you might get a lot of issues. That's something I'm aware of. Maybe other forum users can share their experience on using RPI with BTSync.

@kenshinx34 Thanks for your feedback. @Boatguy, Well - after changing the excel in whatever app on iOS you have to send it back to BTSync. As @hungarianhc mentioned - this is an Apple limitation. @hungarianhc, Thanks for the issue report!

@rookey, Please note, that BTSync is in beta now, so some of unexpected issues are still happening, though the team is working hard to make BTSync very stable and reliable. Now regarding your issues .SyncIgnore issue try adding directories in \<directoryname> format, i.e. add leading slash or backslash depending on your OS. Old TrueCrypt volume overwrite issue It is a known interoperability issue with a TrueCrypt. When BTSync adds new files, it calculates their hash and remembers mtime and size of a file. However, hash calculation is a very costly operation from both CPU and HDD usage POV, so BTSync can't calculate hashes without solid reason. The trigger to believe that file has changed for BTSync is change of file's mtime or file size. And, TrueCrypt is a security application which wants user to be secure: when you change anything on TC volume, it is NOT changing the mtime of volume file size intentionally. In this case BTSync has no chances to find out that the data has changed or which version of TC volume is the latest. Solution here would be to set an option in TrueCrypt to force it updating the mtime. Hope it will help to bring your trust back to BTSync

@playontv, It varies by platform. Here are brief description of the rules: Android Sync runs in background. Application must be running. Auto-sleep option allows to shut down the core (to save the power) and load it periodically to perform the sync in background. iOS Sync runs in background for couple of minutes, there iOS stops it. For now all must be open on the display for sync to happen. WP Sync does not run in background, app need to be open for sync to get going.

@pokho, Thanks for the feedback. Let me share my comments. Think of it from another POV. If user changes file in RO peer - he understands what he is doing and he wants to keep modified file rather than one from remote peer. This looks to be more user-friendly. This is the way BTSync works. When you change (delete) the file in RO folder - BTSync remembers that this file is no longer a subject to sync. So it won't keep an eye on it anymore. Even if you rename it back and delete same file on RW peer. As for your feature request - put it also in the Wishlist, so we can keep track of it.

@Rizwan, It looks like all the scenarios you describe are okay and Sync is acting as designed. Could you please elaborate which behavior do you expect to see in which scenario? Read-only key allows to add new files to RO folder (they won't be transferred to RW peer), file removal (they won't be removed from RW peer) and file modifications (again, won't be moved to RW peer). All the changes on RW peer will be synced to RO peer, except if file was modified / deleted - in this case it stops being synced from RW peer.

@milleri, .SyncStreams is a white-list file which can contain records about streams \ xattrs to be synced. It supports the same format as .SyncIgnore file, so wildcards can be used. However, to get rid of the xattrs being synced you need a .SyncIgnore, not .SyncStreams. .SyncStreams just complements defauls xattr whitelist with any user's xattrs.

Dear forum users, As many of you know, BitTorrent Sync client is localized to many languages, and one of languages supported is Korean. I would like to ask Korean native speakers to take a look at the localized Desktop and Mobile clients and provide a feedback about the quality of localization and possible mistakes / typos. Please note, that Korean localization is available only starting 1.3. Looking forward for volunteers Thanks!

@Bruno, There is no such functionality in iOS client right now - but I suggest adding your proposal to the Wishlist.

@jjayce, I don't think it is possible to limit access per-user: even API has the folder as the tiniest bit of granularity which can configure the access level. And BTSync won't let you add the same folder with the different secret twice. So you can implement a per-folder access level distribution.

@citronbleu, Great - please communicate support team over ticketing system so we can help you resolving your ticket!

@Blacky, That's right. This way is applicable only on full migration and old computer should not be working anymore. If you just want to duplicate settings, this way is going to cause really nasty issues, hard to identify and debug.

@grilledsandwich, Just to make sure - did you download BTSync for ARM - and it still shows you such error? If you are confident, could you please try to run the following command in console and let me know the output: cat /proc/cpuinfoThanks!

@captainmark, Actually it shows that your mobile phone provider does not block at least TCP outgoing to port 3000. Could you please try to download the file from your phone "config.usyncapp.com/sync.conf"? Also, do you have another PC connected to the internet so you can make sure that issue is bound to the phone, not to the PC? If you don't have another PC - let me know, I'll share some test secret with you so we can see if our PCs connect.

@Jack, Thanks for the details, it is much more clear now. Yes, please, the logs have good chances to find the root cause. Note, that I'll need at least one log from your Linux peer (turned on to full debug output) and one log from Android peer. The event of "Android returning to home network" should be reflected in both logs. On Android just tap a Feedback to send logs, leave a link to this forum topic in the feedback form so it will be easier to associate the ticket with forum topic.

@SpencerH, Great, glad to hear issue is solved now!

@hungarianhc, Great. But if something crashes - I'd prefer to get core / crash dump, as it usually contains at least a call stack which can point us to the problem location.

@captainmark, There might be some bad news for you. Your ISP might block the traffic from Android to the tracker server. In general, BTSync requires connection to t.usyncapp.com and config.syncapp.com domains over TCP or UDP port 3000. If it is blocked by your ISP - your device connecting over mobile network won't be able to see and communicate any other devices. I suggest checking it with your ISP.

@beo6, It looks like you try to make BTSync creating folders on network location over SMB. Try mapping the server to local drive letter and see if it helps.

@horvatha, What is your MacOS version? Isn't it 10.6? Also, when the issue happens - could you please try to hit CMD-R to refresh the directory without restarting Finder? Also, could you please try to turn on a hidden files and see what is happening in the directory when History says that file already synced? If you'll see that file that was just synced (but still invisible) is saved to dir with "!sync" extension - the sync might simply not finished yet and you need to wait a bit until file gets renamed to proper name and hidden attribute gets removed.

@mcai8rw2, Does your Ubuntu and Windows "see" each other? (Win should be displayed as peer in the table of WebUI on Ubuntu, while Ubuntu will be visible as peer in Devices list in Windows UI) Are your computers in LAN or they are connected thru WAN? The log message you put here actually is not that critical. It just displays the fact that BTSync did not manage to map the port with your router using UPnP protocol. It is not deadly as there is still PMP, NAT punching and relay server at the end of the day. I suspect that you have multiple NICs and BTSync has a known issue when working on systems with multiple NICs functioning.