RomanZ

Hi storx, Now you need to set up BTSync on your PC or mobile device, add a folder to Sync and put the same secret you did on your MyCloud device. Please see user guide and getting started sections for more information.

Hi, When BTSync delivers files from other peers - it sets them modification time exactly as remote peer has. In your case BTSync fails to set modification time, most likely because the user running BTSync is not the owner of the folder (I guess that in case of vfat - not the owner of mounting point). As a result, BTSync sees difference in modification time and starts re-hashing file pieces to find where is a difference (and sync it, if any). To get rid of this issue you need to make sure that user which runs BTSync on Linux machine is the owner of the folder where data is synced.

BTSync is designed to be secure and to allow getting access to data you synchronise only to secret owners. So, Bittorrent does not know the way to identify the type of data and content you transfer unless you share your secret.

MisterRider, It depends on your OS. For Windows you can try "Handle" utility by Sysinternals, which can show you open handles to your Sync folder. However, I'd prefer to get your debug logs for analysis from both peers, if possible.

Hi storx, I did not fully understand what do you try to achieve, but BTSync allows one-way sync. All you need to do is to share a Read-only secret with peer. Having a read-only folder peer will only download data from other peers, but will never upload updated / added files. To get a read-only secret you need to view Sync'ed folder properties. Hope it helps.

Imnotatroll, I suggest that your BTSync stumbled upon some unreadable file / folder (it is a known issue), such as "System Volume Information". Could you please provide a debug log for analysis?

crazyk4952, Thanks for the graphs. The WAN graph is very representative. It is very complex to debug bandwidth issues remotely, so we are trying to reproduce it in our lab. Can you please share as much details as possible so we can build a repro? What are the OSes on both your peers, bandwidth (both peers), router types and configurations, any security software installed? + Any information you think might be valuable in building reproduction. Thanks!

Hi, Could you please share logs with full debug output? It is important to collect logs from both peers as issues might be with both sending and receiving. Thanks.

Hi tebazil, The most common issues are either permissions or firewall. Collecting debug logs can shed the light on what happening in your setup. Here goes the topic with instructions. Thanks!

UPD. You can put "0" to sync_trash_ttl or folder_rescan_interval to disable it completely.

No, you may not modify or otherwise alter any BitTorrent Materials, including logo. Please see “Terms of use” (http://www.bittorrent.com/legal/terms-of-use), Paragraph 5.

Gerard, Thanks a lot for the video, it explains a lot. Does the hang issue happens only during SYNC or it is a constant issue? Also, could you please run performance monitor (perfmon.exe, built-in utility) and see the disk activity and CPU activity when hang occurs?

Hi all, Can you please let me know the time scale on your graphs? What is the period between two peaks, is it a matter of hours, minutes, seconds? Did anyone see the same bandwidth usage pattern in the LAN with lan_use_tcp enabled? cubik, Your graph is 6 minutes long, your download rate jumps slingtly which is okay for UDP. Also note, that BTSync behaves very gently and if it sees that it overloads the channel while someone else is using it - it will automatically decrease speed. lan_use_tcp is not working in your case as you are using 2 remote connections.

pirkojm, Try to avoid putting a lot of files into a single folder on such weak CPUs. It significantly increases CPU load.

This is something I find really strange. BTSync has 2 mechanisms of delivering changes to the peers: 1. Getting notifications from OS that something has changed. This technology highly depends on capabilities of OS and in some cases (for example - network shares over SMB) might be not that reliable. 2. As #1 might be not reliable - once in a period (10 minutes by default) BTSync rescans all sync folders for changes. BTSync does the same when it starts. Strange thing here is that in your case rescan did not found the difference. To debug it - i'll need logs form both machines (note, that you need to have that sort of "unsyncing" file when collecting logs) as well as file name of the non-syncing file.

Hi, Unfortunately Synology NAS DS207 has old GLIBC (2.3) and we do not have a btsync build for PowerPC with such old GLIBC. So, btsync is not supported for this particular NAS unless you find a way to update your GLIBC.

Hi Andy, In your scenario the step #3 ("It reappears back...") should not happen as the file already added to .SyncIgnore on Machine A. I did not manage to reproduce it in my lab. .SyncIgnore file affects BTSync when it indexes files and works for both leech and seed peers, so: 1) ignored files are not going to be forcefully removed, just ignored 2) most likely it won't appear in debug log, so collecting it here would be useless. I can only guess that your "abc.h" filename might contain some local characters and there is some issue with identifying it against what is written in .syncignore. Can you please supply me with your .SyncIgnore file from both "Machine A" and "Client A" as well as the filename you were trying to exclude? Thanks!

Hi Viewmax, The application on Android is intended to work in a background even if only service running. Even with auto-sleep mode on it should get synced once every 30 minutes (or when you turn on the display). Note, that when you push "Exit" menu item in BTSync - you are killing both app and service, in this case your folders won't be synced. Can you please describe in a very detailed way the steps you do to leave service running with no app? Thanks!

Hi, Thanks for the idea, we'll consider it for future release. Also, please make sure that debug log is turned off (for FreeBSD - make sure there is no file debug.txt in .sync folder). If it is off - log size should be really humble.

Hi Mariano, No, the sync intends to fully sync folders, there is no such way to prevent files from deletion. Hi dms2013, You can set the deletion period (sync_trash_ttl value in Advanced settings) to a really big value, like 10 years. In this case you'll always have the up-to-date version of your backup and have all the changed versions in .SyncArchive. Hi Osiris, The peer owning read-only key is going to delete files once the peer owning full key deletes them. If you are experiencing some issues with this mechanism - it could be a bug and I'll need more details from you to investigate it.

Hi Ephemeral, We do not have official package in package repositories. I would advise to take a tarball of btsync from official site. UPD. In such cases I would advise to post your questions in Debian and Ubuntu package topic, so package owners can assist you.

Hi 85aggie, Unfortunately your setup is not going to work. When PC1 and PC2 are going to exchange data, they will also exchange all information about peers owning files, so PC1 will know that there are other peers in internet and will sync with them also.

FreeBSD does not provide an option to get directory change notifications like other OSes do. Therefore, the only way for BTSync to detect changes is a folder rescan.

It is necessary to have full logs enabled when issue pops up, otherwise it won't get into full log. You can disable logs to save the HDD space (full logging is pretty space-consuming), but short version of log usually is less useful in issue analysis.

sebforeb, Thanks for the explanation, we'll consider your feature request for future versions.