RomanZ
-
Posts
3,588 -
Joined
-
Last visited
Posts posted by RomanZ
-
-
jwilker,
I don't see your attachment. Some other error is happening?
-
Hi Minh,
I suspect that you've installed prepackaged version of BTSync from Synocommunity. It creates an additional user called btsync, so it indeed might lack of privileges to access your home directory.
I would avoid running BTSync with root privileges: from security prospective of view you should not provide so much privileges to application when it does need them.
I would advise either fixing permissions for your users / groups or running your btsync under the user which home directory you would like to share.
-
Hi kda406,
Unfortunately speed limits work not that well when we are talking about small values around tens of kilobytes per second. It is a known issue and some day we are going to resolve it.
-
Sure, my pleasure.
Please send logs to "syncapp@bittorrent.com" as attachment, pack if possible. Let me know when you are done.
-
Johan,
Indeed, not too much info in the log. Unfortunately, I did not manage to receive core dump file. Can you please resend it?
Thanks!
-
Usually this issue is reproduced only when renaming and changing symbol case.
I'd like to find the root cause of this renaming duplication, but I need a little more information from you
1. What is your OS? Version of BTSync?
2. Could you turn on debugging logs, reproduce and share logs to me?
Thanks!
-
abc123,
I see a message indicating that BTSync get blocked by windows firewall. It could happen due to one of next reasons:
1. You did not install the application, but copied it instead (During installation procedure we ask Windows Firewall to let us open a port for listening).
2. During BTSync installation you unchecked the box "Add exception to Windows Firewall" or refused to do it in case if Windows asked.
Most likely this is the reason why you can't receive files from other peers. You can reinstall application or add exception in Windows Firewall manually.
-
Thank you for the log in ticket #7286, it helped us to pinpoint an issue with Syncing localized user profile in Windows. BTSync stumbles upon some folders it manages to enumerate but does not manage to read. Developers are investigating how it can be fixed.
Unfortunately, this issue lead to another known bug - when BTSync can't read some folder, it stops file indexing. This is the reason why you got synced only 8 files. This issue is known and is fixed in upcoming release.
I apologize for the inconvenience, we are doing our best to fix issues and make BTSync stable and reliable.
-
Hi jlacroix,
1. The issue is known only if you rename the folder which changing case. Did you rename the folder in a different way and got the folder duplication issue? If yes, this is a new issue which need to be investigated. More details (OS, BTSync version, logs) are appreciated.
2. Should work fine. Just note, that it won't sync files immediately after you roll back the snapshot - it needs to contact peers, update the directory tree and all the changes, etc.
-
Hi jwilker,
This error is shown when BTSync was unable to write service data in the selected folder. It usually happens by one of 2 reasons:
1. The folder you select does not exist (or you just forget to select it).
2. The user running BTSync does not have enough permissions to write data in the folder.
Just to make sure you did not miss the important step: when you add new Sync folder on your Mac - you need to put both secret and choose a folder, like on a screenshot below. If you leave "folder" blank - you'll get the error message.
If this is not the case - could you please try adding different folder and check if you get the same error message?
-
Hi Mani,
BTSync is not intended (and does not support) syncing folders on the same device. I see 2 options to make the setup you want:
1. Install BTSync on your NAS if it is supported (see topic here for supported NAS variants)
2. Decentralise your docs folder. You can install BTSync on all peers requiring docs and they will keep folder updated. Obviously, this way of working has it's own advantages and drawbacks.
-
Hi gerard, whoozy,
When BTSync encounters files it can't sync due to filename limitations on other peers it will attempt to sync once and stop (at least until the next full rescan). In the devices list you'll see that some data is still need to be uploaded, but BTSync icon in system tray won't roll.
I suggest that some application is constantly updating some file in Sync folder. To find that out for sure - I'll need debug logs, here goes the topic how to collect them.
-
Hi pirkojm,
CPU (and, actually, RAM) usage is highly dependent on amount of files and folders that your Sync'ed folder has. To find out the difference BTSync has to calculate a large amount of hashes for the files stored on storage.
Keeping in mind that Raspberry PI has not very strong CPU, even hashing task might be heavy for it. How many files and folders do you have? Is there any folders with excessive amount of files?
Your actions (especially - removing encryption) are fine to lower CPU usage. I would also advise to increase rescan interval even more (to, say, one day) and see how long is it going to take for RPI to index all of your files (the CPU usage should go down of no actual syncing is happening now).
-
Hi megamorot,
Unfortunately FreeBSD version of BTSync cannot track immediate changes on file system due to OS peculiarities. So, sync folders on FreeBSD are updated only during every full rescan interval, in your case - every 10 hours.
-
Hi Gerard,
Unfortunately dump does not reveal the reason. Everything looks functional, no any hangs, deadlocks or objects to be waiting. Let's try another approach.
Did it happen from the very beginning or after adding some folders / files? If after eddying - is it possible to try removing folders from btsync to see which one causing such issue?
-
Thanks. I guess your timezone and system watch are set correctly? if yes - the answer should be covered in the logs. As soon as I get a pair of logs and analyse them - i'll update the topic with results.
-
It is definitely not iOS issue. iOS application has no full functionality due to OS limitations, so file deletion won't cause them to be deleted on other peers.
Android is different story: BTSync on Android is a fully functional client. So, if files on Android were deleted (or, for example, moved do a different location) - BTSync will decide that they were deleted and sync change to the rest of peers.
I do not know full algorithm of actions of Clean Master, but its actions might be a reason. For this case you can make your Nexus device a read-only peer to make sure it won't affect your photo collection.
-
There are plenty of online string base64 encoders over internet, you'll need just to put some text to one editbox and grab encoded one from another (base64 always contains only printable characters so you'll have no issues to copy-paste it).
-
Hi proudwvhilljack,
Secrets are stored in BTSync files. If you want to get a secret to share it - take a look at Sync'ed folders in BTSync properties, there are several ways to share them (copy to clipboard, copy a read-only part of a secret, display secret as QR code, etc.)
Sharing of a secret and security of it's delivery is up to you. You can mail it, type in manually, share thru instant messenger, scan with QR scanner, etc.
-
Hi,
I would appreciate if you can share full debug logs from both machines as well as crash dump of crashed process (should be in .sync subfolder in the same place where btsync binary stored).
As soon as dumps and logs get analysed - I'll share results / recommendations.
-
Hi deh,
1. BTSync does not use your PC and bandwidth for some other peer-to-peer transfers. It uses your bandwidth to transfer data only for Sync'ed folders you configures.
2. BTSync generates some service traffic even when no updates are actually done (it has to contact tracker, contact other peers, etc.) Total of ~5Mbytes of data for both upload and download per day is definitely okay for service traffic.
-
Hi k9xZU9pz,
Yes, it is possible to create a custom secret. You need to make sure that it is base64 encoded AND it's encoded length is not shorter than 40 symbols.
-
pagesx5,
Maybe a description is a bit vague. When BTSync is running on PC / Mac, it shows itself in a system tray (small icon to the bottom right for Windows and to the top right of screen for Mac). If you right-click on it - you'll see a popup menu, where you can enable logging.
-
Hi,
The only limitation for BTSync are OS resources. Roughly, one file consumes 400 bytes of memory. This makes your setup worth of nearly 2.5Gb of memory space - which is pretty much achievable on modern PCs.
It's a little bit harder with CPU usage. Every file needs to be read, hashed, encrypted, transferred, decrypted. Just a reading of whole directory from hard driver is going to take a lot of time - and going to take even more when calculating the hash of your sync directory tree.
Technically BTSync should be capable of handling all these files, it is just going to take longer.
Some questions to understand more clearly what happens in your setup:
1. What is your Linux machine HDD background? CPU architecture? Memory amount?
2. How these files and folders are distributed? Evenly or there are some excess cases like folder with 100k files/folders inside?
3. What do you mean under "BTSync freezes"? It does nothing? Never responds? Can't connect to UI? How long did you wait?
4. If you can see the UI - did btsync finished indexing and shows amount of files and data volume to be synced?
5. Finally, the logs. We can try to find out precisely what happens in the BTSync if you turn on debug logging (instructions here).
Troubles With Sync, With A Netword Harddrive Via Win & Mac
in Sync Troubleshooting
Posted
Hi bildebool,
BTSync compares sync'ed directory trees upon startup and every folder_rescan_interval (which is 10 minutes by default), so it should sync your folders after startup.
Does UI (devices tab) shows you that there are some data to upload and download on both machines?
For full issue analysis I'd like to get debug logs for both computers as well as couple of filenames that were not synced when you collected logs.
Thanks!