RomanZ

@suhrim I suggest that you've copypasted the key to avoid any possible typos. Please also make sure that the text editor did not put any extra line breaks in the API key. If all of the above is not the case - please send me your config file with the key, I'll test it in my lab. Please use syncapp@bittorrent.com mail address and refer to this forum topic.

@VFXLegion The fact that files and folders are removed on your "master" share when removed on another is okay and by design. The RW peers are equal among themselves, so if any of peers deletes a file / folder in a share - the deletion will propagate to other peers. Though, you can share the Read-only secret with your Boulder artist, so the changes he does in his share will not be propagated to other peers. As for the bigger files that are not get synced - it sounds like some bug / issue. Let's try to debug it. First of all - we'll need debug logs collected from 2 peers (one that wants to send the files, another that does not receive them) and couple of filenames that were not synced. We'll try to find out what is happening in the log. Send logs to syncapp@bittorrent.com, refer this forum topic in the message body.

@SamD Do you have any files / folders containing some special French characters? If yes - could you please check if conflicted files are limited with files containing non-latin characters? If this is not your case - then we'll need debug logs from your both computers to start finding out what happens in your case. Send them to syncapp@bittorrent.com, refer to this forum topic.

@SamD The .conflict files appear when one file on a peer is mapped to another file with different name on another peer. The most common use case is when files are recorded in different case between 2 Windows machines. So the first thing I suggest to check if files producing conflicts has different letters case.

@Bones Please collect debug logs and send them to syncapp@bittorrent.com for analysis. Logs should contain the period when sync suddenly stopped and should be collected from 2 peers (we do not know which peer is the reason for non-transferring files).

@VFXLegion Could you please elaborate about non-supporting file structure and did you manage to fix it? Thanks!

@proactiveservices Once auto-updates will track the latest version (even with one week delay) there will not be need to keep "The latest" thread.

@baj3810 The .conflict files and folders are usually created when filename on one peer is mapped to a different existing filename on another peer. Usually it is bound to upper-lower case of a filename on Windows machines (however, other options are also possible, for example - with composed / decomposed characters specific to certain languages, like umlaute in German, etc.) In your case the most probable scenario is that some application (editor? VCS?) is changing the case of a file or folder, which brings you a conflict files and folders. Which apps are working with files in your repository on Windows and which on Linux? We'd like to try reproducing it in our lab to improve BTSync behavior.

@NeilCH We are working with QNAP actively to provide an official package. It should happen really soon, but can't provide exact ETA, sorry.

@BigCookie Yes, it should work fine. No changes in interfaces / files / formats. So file replacement should go smoothly.

@gmosquera BTSync does not sync !sync files for sure as they are treated as service files (like .syncid, .syncignore, etc). These files appear when BTSync transfers files from other peers. Once transfer complete, it moves old file to .SyncArchive and renames !sync file instead of moved one. So it is a temp cache for incoming files. I suggest that some files can't be transferred completely, that's why you get !sync files stuck in your system.

@theratman Do peers see each other in "Devices" tab and traffic is not going, or peers even are not displayed?

@scegg, I also advise setting log_size to ~200, so we'll have more chances to grab it in the log. In this case logs will occupy up to 400 megs on your HDD.

@sbrattla It is out of btsync functionality. It does not sync ownership and permissions - only filename, content and some properties like mtime and xattrs.

@benplumley Yes, if you have a strong pass - you should be on the safe side. @aaronmk It's not new. It was present in 1.2 for sure. During a very first run BTSync requests for a password - see screenshot below.

@JimKnopf Seems we've managed to simulate behavior in our lab. Thanks for reporting, we'll analyze this issue.

@benguild Reproduction confirmed in our lab. We'll take a look how can we fix it.

@hungarianhc It is a known issue. T-Mobile USA throttling BitTorrent traffic intentionally. We are working to resolve this issue.

@onesolo Every version has it's own problems. I see no point in flushing all of them into hundred-pages-topic. Every release gets it's own topic. As for the auto-update issue - it will be fixed soon. We plan to publish new version to the forum slightly (1-2 weeks) ahead of auto-update. So then you can rely on auto-update.

@FrellPumpkin There is no limitation in BTSync. It is limited by resources of OS where it is running. When you have big amount of folders / files, your Synology might run out of memory. It takes in average around 400 bytes per file/folder, so your 37k of files are going to take around 15M of memory. Please check if this is affordable on your NAS. Also, I guess that something other happened that prevents BTSync finish indexing - most likely, some permission issues. I suggest collecting debug logs and sending to our support e-mail, syncapp@bittorrent.com

@scegg Do you mean that file deletion goes fine while transfer of a new file does not happen unless you restart the client? Then issue is definitely not in DNS resolution. In this case we'll need debug logs for both your peers to see what happens. Please send them to syncapp@bittorrent.com, refer to this forum topic in message body.

Hi all, 1. Please check that when transfer stops - your other peers are still visible in the devices list. 2. Turn on debug logging. Mark down the time when "traffic not flows". Send both debug logs (at least 2 peers necessary, which do not transfer anything) to syncapp@bittorrent.com. We'll try to find out why it happens. Refer to this forum topic in your mail with logs.

Well, then we need logs to see what happens between your RPI and Tower PC.

@SentryTheDefiant Please see this topic - it says where debug logs are stored. Also, BTSync never deletes the file or folder without moving it to .SyncArchive. Please check .SyncArchive on other peers - or see if there any other application which could remove the folder.

@datroubler I wonder if this file is not open by some application which prevents BTSync to read it? If you are confident it is not - please also make sure that user running BTSync has enough permissions to open this file. If all is okay, I suggest collecting debug logs from both RPI device and your Tower PC and sending it to us for analysis to syncapp@bittorrent.com. Please mention this forum topic in the message body as well. As for the auto-update - it is slightly behind the latest published version, but we'll publish 1.3.106 to auto-update as well soon.