RomanZ

Hi necula@cs.berkeley.edu, Currently .syncignore is not synced automatically, and as you noticed - either BTSync need to be adjusted to understand cross-platform semantics of .syncignore, or it should sync it in a smart way to adjust semantics according to local OS. Thank you for feedback, we'll consider it in future releases. I suggest also posting to wishlist.

Raccoon, You can try to write to ExtSD to folder "/Android/data/com.bittorrent.sync". It should be working in 1.2, this is the only folder allowed by Android OS for RW access for BTSync starting 4.4.

maikeldus, This is the BTSync design: all available peers participate in sync. If your server communicates to Laptop with the help of Tracker server - it will immediately let Laptop know of Desktop existence (and IP addresses) and vice versa. So, disabling tracker-relay-DHT settings on your Desktop only is not going to help. The fact that clients are read-only does not mean that they are not going to seed data. If the data is not changes (which is assured with digital signature), RO peer is going to seed it to other peers. I can only think of limiting bandwidth in BTSync preferences, as usually it only applies to internet connection and not to LAN. Please check if this option fits you.

jonnojohnson, Indeed - .SyncID is totally necessary to identify the folder. Removing it causes BTSync to stop recognising Sync folder. If you have some development force you can think of using Sync API which allows to do a selective sync of files, so your script / app can go over folders and choose what to sync actually.

BengtSv, Looks okay. Couple of comments on debug logs: 1. If issue occurs, the probability to catch issue is much higher if we have logs from all peers involved in issue (usually, 2). 2. Don't keep debug logs on for too long, as they are going to consume really much space. We are working to make log rotation in future releases, but it is not yet present in 1.2.

Power2All, It actually depends on your NAT behaviour. UPnP and PMP won't work, so it will try hole punching. If your NAT is smart enough to start switching ports - BTSync won't manage to connect and will initiate connection thru cloud. If it is not smart enough - BTSync will install a direct packet exchange (I avoid "connection" here as BTSync actually sends UDP datagrams and does not connect as it would be done over TCP protocol).

onyxogen, Sorry, but i'm really missing the point where bug is. I did a couple of tests as you recommend: Test #1. WinXP bears a role of Encrypted-RO. Windows 8.1 as RW node, which shares the file. File is stored in deep folder: C:\users\test\desktop\SyncEnc2\SubFolderEncr\[subfolderEncr 25 more times]\lua.dll SyncEnc2 is actually synced folder. Path is 100% longer than 260 characters. Windows Explorer complains about long path somewhere on folder level 15. Sync is done successfully, XP gets encrypted file on the same level depth. Test #2. The same, but RW node was iMac. Also, no reproduction, all the folder path was synced with the file at the bottom. And actually there should no be any issues by design, as on Windows BTSync is using a Unicode version of file API which is limited to ~32Kb file path length. Could you please: 1. Advise if I correctly got the idea of your test. If yes - any issues / mistakes you see in my test (except I did not grab Win7, did not had one at hand) 2. Share your use case? Are you using some extremely-deep tree to store data? 3. Share the screenshot of the error you get. Who is producing this error?

haberjr, QNAP NAS HS-210 is running under embedded linux. BTSync for Linux has a webUI interface, which is protected by login and a password. Could you please try to put default login with password? I suggest it would be "admin" with empty password or with "password" password.

There is a setting in folder properties, see screenshot attached. Unchecking it will prevent deleted files to move to syncarchive, Sort of. In your sample, for server #1 if there still data to send - you'll see non-zero value in "Upload" section. Server #2 will see data in "Download" section.

Hi all, Versioning is working in next way: every time sync is delivering new file, the old one is moved to .SyncArchive. If SyncArchive already contains one, then ".n" is added to the name of file, where n increases from 2 and to ~4 billions. Note, that it is not every time when you save the file. It takes around 10-20 seconds to actually start the sync, so if you are saving file often - it can kick off the timer again. There are 2 settings which might affect behaviour: in folder preferences there is a checkbox "Store deleted files in SyncArchive" (which is checked by default) and in global app preferences, advanced: - max_file_size_for_versioning, default value is 1000 (Mb), which means that files bigger are not stored in SyncArchive. - sync_trash_ttl, default is 30 (days), indicates how long files are stored in SyncArchive folder. If you change your files, changes are synced to other peers and other peers do not store it in SyncArchive with increasing number - it sounds like a bug. Details (file types, OS&environment, debug logs) are appreciated.

j2b, There are at least 2 ways to achieve what you need. 1. Disable moving files to sync archive on server #1. 2. Wait until file appears on server #2. When !sync file is renamed to the real file name - it means that it was delivered, not damaged and it is okay. 3. Remove file from sync folder #2 on server. It will be automatically deleted on server #1. Second way, use API. When using API - call command "Get folder peers". When "upload" and "download" equal zero indicate that transfer is complete. You can use it to check if file was actually transferred.

I'm here to answer questions. FAQ recommends to keep .syncignore files same on all peers. If this is true: If some files are excluded, BTSync won't calculate them in files amount value and summary data size in UI. Also, it will show peer as fully synced when all non-excluded files are synced. If syncignore is different, next scenario applies: Say, we have PC A and PC B with some folder synced. PC A has *.abc files ignored. It also has bunch of other files as well as several .abc. After sync done, PC A will show that it is synced with PC B, amount of files and volume includes all files except .abc. PC B has bunch of files as well as several .abc. After sync is done, PC B will show that it is yet to upload a number of files to PC A, their amount and volume is a sum of all .abc files that are on PC B. It might mean: 1) remote node is RO and some files are deleted / modified 2) remote node has some files ignored and simple won't accept them 3) remote node is mobile device and synced only part of files due to selective sync. 4) some issue occurs that prevents files from syncing completely (permissions, letters case bug, locked files, out of free space, etc.) Yes. One of the cases is when user changes / deletes the file on RO peer and settings prohibit from re-syncing it.

Hi syncingpossum, Thanks for the feedback. We'll consider changing default settings for LAN and will definitely take care of configuring some "default" folder settings so they would be: 1) applied on folder creation, not later, 2) applied automatically to avoid possible manual reconfiguration mistakes. Roman.

onyxogen, Actually Windows allows around 32k for the full path and filename. BTSync is using the API which does not limit file operations to MAX_PATH variable (which is only 260 bytes), while Windows Explorer uses older API and might have issues displaying folders and files, which has summary length more than MAX_PATH. However, there are bunch of file managers over Internet, which are able to browse long paths with no issues. Could you please share what is your usage scenario which makes long paths an issue? AlwaySyncd.com, Linux has a limitation of 4k for path and file name. Terminal should not have any issues, also it looks like shells (Gnome, KDE, etc.) also have no issues.

Hi soebo, I've sent you a list of problematic files. It looks like they were renamed with only case change, which is a known issue for BTSync. I consider to re-sync them. We fixed this issue in upcoming release.

BengtSv, Thanks for the feedback. Do I understand correctly, that after you realised that files were reverted to older version - .SyncArchive on Macs were empty and did not contain previous versions? BTSync should save all the files it overwrites to .SyncArchive, so it can help you realising which files were actually rolled back. Also, did you had a chance to grab a log from NAS-es / Mac? This could help us to find the root cause of the issue. If your NASes still does not see Macs - please check your router settings and firewall settings (if any). For local network discovery we use multicast address 239.192.0.0. over UDP 3838, to contact tracker server - UDP 3000, they must be allowed in firewall / router so devices can "see" each other.

Hi soebo, There are several possible reasons for your issue: - permissions (one of peers can't read / write particular file(s) or folder(s) - File lock (some file can be locked by an application so BTSync can't open it) - Different file name case (file(s) could be renamed by you or application with only letter case change - known bug in BTSync) - not enough space on peer to get the data You can check the bullet #2 and #4 easily (#2 - use "handle" utility by sysinternals to see who has open handles to your sync directory, #4 - check the disk free space). If that does not help - please make a debug logs from 2 of your peers (one which wants to send, another which can't receive) and send to me for analysis.

Hi Dimtar, Say, Computer A is downloading the file. It is going to download the file from all available peers and it is going to request missing parts of a file only. So, if everything is going ideally, it is not going to request duplicating pieces of a file from other peers. Only one chunk of file from one peer. However, that happens in an ideal world. In real world: a. There is some amount of service traffic around actual getting of pieces. b. There is a special logic detecting damaged pieces. If peer got a damaged piece, it is going to request it from other peers trying to find out who is sending damaged pieces of the file. c. If some piece was not downloaded completely (for example, peer is not available anymore), it is going to be downloaded again from another peer.

Hi, There is no way to force service files to another location. They have to stay in a synced folder. Note this feature in Wishlist to ensure it is not lost.

noiime, Only Linux i386 and x64 are subjects to the issue, so only these 2 builds were updated on official download page. You can use the link above, but it is recommended to download from link in first post.

fantom, Thanks a lot for your assistance. The issue is fixed in 1.2.92, build is available on BTSync download page. tuxpoldo, This is btsync issue indeed. Please use updated build.

Dear users, BTSync 1.2.92 build is available on our download page. Build contains single fix: - fixed issue with subscribing to multicast address (linux i386 and x64 only)

Yes. Means - applies to current folder and all subfolders. Right. Slashes should be OS-specific. "\" for Windows, "/" for nix-based OSes. One should use relative paths in syncignore. Correct. Did not encountered specs like this one. Double star does not make much sense, should be working same as single star.

All, Due to Android OS limitations only next path would be possible to sync on External SD card: <path_to_sdcard>/Android/data/com.bittorrent.sync

JM7833, It is possible to sync between real machine and VM. Please check network settings of the VM application, as it usually has several options on how to connect your guest machine to the network (NAT, bridge, emulated network, etc.). The fact that remote machine does not see your VM indicates connectivity issue: these 2 machines can't exchange multicast packets (239.192.0.0 over UDP 3838) AND some of them (presumably VM) can't reach tracker server (t.usyncapp.com, UDP 3000). Also, check settings of host machine firewall - it also could be the reason.