RomanZ

Hi Andreas, Thank you for the positive feedback. BTSync is in Beta now, so we are doing our best to catch and fix bugs in real environments. Usually such bugs with files coming back are happening indeed due to significant time difference between peers. Could you please turn on debug logging for a day or two to catch the issue if it comes back? Don't keep debug logs longer, as they are going to occupy a lot of disk space. As for the second issue - couldn't it happen that some of image viewer is meddling with files? For example. updating some thumbnails / DB files in your folder? The fact that BTSync decided to re-sync folder means that the hash of the folder has changed, i.e. either some files are changed, or new ones appeared.

Lukas, no, it should not be a problem. If there would be owner / permissions issue, the files would never be synced, while they are synced only after full folder rescan. Could you please collect full debug log on the affected peer? Thanks!

dms2013, Please try to add syncapp.bittorrent.com to hosts with IP 23.21.106.161 - just in case if only DNS name is blocked, not IP. We'll put the whole list of changes and when 1.3 is released. It is still being developed so we don't want to set any false expectations.

Hi all, This is a known issue with KitKat. The fix will be available in the upcoming 1.3 release.

Hi all, Here is a new desktop build, 1.2.91. The main release change is compatibility with upcoming 1.3 client, plus some minor fixes. List of changes: Upcoming 1.3 compatibility Fixed issue with permissions transfer on Linux and Mac during initial scan Fixed issue with sync getting stuck after folder removal Fixed issue when deleted files get restored after peer comes online Fixed issue when new version not checked on Linux and FreeBSD

Hi all, Yes, this behaviour is designed. As soon as hash of the file changes (i.e. some actual data is modified) OR file is deleted / moved outside of the folder, the BTSync marks it with "Invalidated" flag in database and never re-syncs back. This behaviour can be adjusted. In BTSync, in folder properties there is a setting "Restore modified files to original version" which is unchecked by default. You can check it and BTSync will restore files when they are changed / removed.

Wheezy is using glibc 2.13 or newer, so it definitely supports notifications. Only one thing I can think of is that your sync folders has excessive amount of files and OS ran out of inodes Could you please run the following command from command line and copy-paste me an output? df -hTi Thanks!

Hi all, We know why this message pops up in the log, and eventually will fix it. It should not bring any functional or usability issues to your BTSync, so just ignore it for now.

Hi wimbit, BTSync crashes due to weak secret validation mechanism. This issue is solved in upcoming release. I suspect that you put some illegitimate symbols in your secret or just did not base-64 encode it. Let me show you an example. Here is the secret (without quotes): "1234567890!@#$%^&*(),./\';][=-qwertyuiop" If you put it into BTSync, it will either crash due to bug in validator or refuse to get such secret. However, if you encode it to base64 it is going to look like (again, no quotes): "MTIzNDU2Nzg5MCFAIyQlXiYqKCksLi9cJztdWz0tcXdlcnR5dWlvcA==" And is going to work. Base64 format is 30% longer than binary, but it contains only printable characters (letters, digits, and + and = signs). Please make sure that the custom secret you add is base64 encoded. You won't be able to adjust it in UI due to crash which will occur when you open a folder properties, so simply remove folder from BTSync UI and add a new one.

Lukas, Could you please share details of your OS and environment? Full version, security software (also with versions) if any, disk encryption utilities with versions (if any).

Yes. BTSync goes over all the files in DB, removes the “Don’t propagate” flag and requests the torrent file (list of hashes for file pieces) from other peers. File pieces that are changes are re-downloaded. Currently BTSync has no UI which allows change “Don’t propagate” flag on file granularity level. Both. BTSync checks ignore list before requesting files from remote peers and never tells other peers that it has such file if it is in ignore list. Please see more in http://forum.bittorrent.com/topic/17782-bittorrent-sync-faq-unofficial/, specifically section “How do I use "*" and "?" wildcards in .SyncIgnore files?” Not precisely. Files that are not on RW peer won’t get into database. Once they appear on RW peers, RO node will add them to database and IF they are different from RW peer - will mark them as “Changed, do not propagate". These files won’t reveal us the root cause.

Hi rootadmin, No, there is no upload notifications now. I suggest adding idea to the wish list, which is a pool of ideas for future releases.

Hi PeterVerhees, Custom secrets are supported in BTSync, but not in API. In BTSync you can put custom secret encoded in base64 with length of 40 symbols or more. For API you can use custom entropy pool to generate 20 byte binary, encode it to Base32 and add a prefix symbol "A" for RW secret, "D" for RW secret with encryption.

Hi wilbertcr, I cannot explain what systemctl status displays you as you used some custom way to install and run your btsync. However, I still can take a peek into debug logs if you can collect them for your peers, preferably from two of them simultaneously so I can compare events happening on one peer to events on another. The most usual issues which bring the "Sync Stuck" issue are - incorrect permissions so indexer can't read a file / folder - Some file being locked by an app - changing the filename case but this is not your issue as on Linux they are treated as completely different filenames. So please try to collect debug logs and throw to me for analysis.

Hi all, This is a known issue. Indeed every ~30 minutes some data is written to disk by BTSync. We plan to optimize it in future releases to make sure it does not wake up HDDs.

Chizbang, Currently BTSync can't make it much faster. After receiving system notification on file change it takes a while (10-15sec) to make sure that the OS or App is not going to do any additional changes to the file. Also, peers exchange the tree synchronisation messages every 10 seconds, plus it takes a while to merge the file trees itself. So even if you set up the folder rescan interval to a very humble value, it won't make sync start faster.

dms2013, Please make sure that your Android is indeed using local network. From the symptoms it looks like it tries to connect via mobile internet (and gets a wrong tracker IP). Android clients also issue a Multicast packets to detect peers in local network. I especially did the test in a lab: a wi-fi network with no access to internet - Android devices manage to transfer data and generally "see" each other.

We have the photo viewer in BTSync. It does not allow to scroll photos conveniently as Camera Roll can, but we plan to improve it in future.

Hi iceboy, Sure. 1. Open your BTSync on Android. Tap "Add folder" 2. Choose folder you want to backup, tap "Next" 3. Deliver the secret to your PC in some way (mail, manual, etc.) 4. Install BTSync on PC, add new folder in BTSync, put the secret you've got in step 3. 5. (Important) in Preferences->Advanced settings find "sync_trash_ttl" parameter and set it to "0". All photos you delete on Android are going to be moved in .SyncArchive folder on your PC, so step 5 is necessary to ensure that BTSync on PC never deletes them from SyncArchive (by default it deletes file from .SyncArchive after 30 days).

stanha, I apologize for imprecise information. Touching file on a peer won't force BTSync to think it is changed. Actually, if BTSync realises that the file actually did not change (file hash is the same), it will bring MTime back to it's original value. So, to make a file actually non-propagating on a read-only node you need to change content or delete (move out of the folder). When content is changed or file is removed, the BTSync "forgets" about the file unless "Restore file if changed" setting is set in folder properties. You can copy it back then, BTSync will ignore. You can also use .SyncIgnore file to make sure some particular files / directories / file types are ignored and not synced. ------------------- Back to the issue of file not synced. Removing sync folder removes DB, completely, including all data about files that was changed and marked to be non-propagating. The fact that allowing file replacement if they changed on RO peer resolves your issue makes me think that files were marked in DB as changed. I don't know why, this might be revealed by full debug logs. Please share logs for analysis if you have them. ------------------- We'll consider your chat and descriptive logs proposals for future releases.

Hi rsansores, I see that you've submitted a support ticket. Please work with us thru support system - and let's publish solution here once it is found.

Thuantran, I guess you moved the file outside of sync folder, right? Please make sure that: 1) The folder you are moving file out is not read-only 2) Check that computers "see" each other in "Devices" tab. 3) Give 10 minutes to BTSync in case if system notification did not work 4) Make sure that your "folder_rescan_interval" is not zero (zero means "never") 5) If all above did not help - please collect debug logs for analysis and send to me to our support (syncapp@bittorrent.com) with issue description.

staalu, No, it is not DNS cache poisoning. The poisoning technique implies that someone who has no admin access to the DNS server manages to change some DN-IP relation in DNS server cache. Either your ISP or some global country server has wrong address, most likely intentionally. dms2013, How your devices are connected to the DLink router? Wi-fi / LAN? How was RPi connected? I can suggest that DLink might NOT transfer Multicast packets between wi-fi and LAN, especially if they are configured as different subnets. Also, shutting down windows firewall is worth checking to find the root cause. Looking forward for your RPi test.

stanha, Glad to hear that issue has been resolved. Could it happen that some apps / users changed files on R/O node so BTSync considered them "changed" and stopped syncing? Even simple "touch"-ing would be enough for BTSync to consider them changed.

Hi Deka, Please don't use custom long secrets with API. It is intended to work with standard 20-byte secrets.