elvenbone

Is there any news on this? Windows phone 8.1 gives access to the phone's user folders which are Music, Pictures, Videos, Documents, Downloads (and OneDrive). One can create subfolders there, copy and move files around, etc. That means it is possible for BTSync to let users select folders on their phone that they want to sync! It's the only feature I miss right now. Will you implement this?

As far as I know it is implemented, but not in a manual, but an automatic, instant fashion: The "Overwrite any changed files" option in read-only shares automatically redownloads files from the "master" source if changed (or deleted) on the read-only side.

Don't worry, this has a very Linux-typical reason that can easily be solved I believe. You may have much linux knowledge and just not thought about it, but just in case you do not or someone else has the same problem, a detailed explanation: Moving and/or Renaming a file (with the mv command) doesn't change the file itself which means it keeps its filesystem metadata, which are ownership (the system user and group that "own" the file) and permissions (read/write/execute permissions for owning user, owning group and every other user/group). When you copy a file (with cp command) it replicates the file's data into a new file. However cp doesn't copy the mentioned filesystem metadata. The new file rather has the ownership of the user you are currently logged in as (e.g. "root" in your example) and who-knows-whatever permissions. So if your btsync instance is not run as the same user ("root") but as another user (e.g. "btsync", see DAEMON_UID value in the conf file) it will not be able to access the copied file. You solve the problem by looking at the old file's properties - The dir command lists owner, group and rwxrwx.. stuff of all files in the folder, alternatively, the command getfacl ./ shows all permission/ownership stuff. Compare the values of the old and the new conf file and ajust the new file as needed: chown myowner:mygroup test.conf ...to adjust the ownership (replace myowner and mygroup by the values of your old conf file, they should be the very same values that are DAEMON_UID and DAEMON_GID in the conf) chmod 740 test.conf ...to adjust permissions if necessary. greetings, elvenbone

Hi guys, I recently upgraded from my RaspberryPi to a BananaPi (with Debian-like OS on it) and installed BTSync 1.4.103. I already have the folders with data in them there because syncing everything would take ages. Now when I add them as shares with read-only keys, BTSync doesn't index the folder! It starts indexing and stops after about 20 seconds. And there it stays, not indexing any more of its own files, whether peers are connected or not doesn't make a difference. The WebUI shows a constant 7B/s as both download and upload speed. Strangely this appears hundreds of times in the sync.log (and nothing else!): "TorrentFile: unloading torrent by timeout" What's happening here? It is definitely not a connection problem, everything else (SSH, SMB, HTTP) works fine (everything is in the same LAN).

Thank you for your great work! There is something where I'm not sure whether it's a bug or a feature: The recent update (normally via apt-get update/upgrade) created a new debconf-default.conf configuration file and afterwards restarted the service with two instances - both my own configuration and the default configuration. That's annoying because I had to stop the services manually and delete the new default conf file again and then restart the services. I have no clue about packaging, but could you implement a check that there is no other conf file in /etc/btsync before writing a new one?

Oh, I only have around 120400 files. So maybe it is really just the number of files that's atte's problem. @atte: If you go for the BananaPi and want to use SATA, be careful about the SATA power connector. Ground and +5V are swapped on the board for some reason no one knows, so you either need to buy a cable specifically for BananaPi or use any other cable and swap the two wires on the connector. Or just stick to USB like on the raspberry...

I installed tuxpoldo's repo and am up to date on that. I must admit my Pi is overclocked to 800MHz, but I cannot imagine that 100MHz make such a difference. Another thought that came to my mind: Maybe you've got some special permissions on some files so that btsync maybe fails at indexing but doesn't say so? And another thing: I put btsync's database/cache/whatever folder on my USB harddrive (see the conf below, /share/.btsync). Maybe you run into problems if you keep it on the SD Card and that may be running out of free space or just very slow?! My conf: (I added my sync folders via the web ui several versions ago and they still work, so I didn't bother to include them in the conf) //!/usr/lib/btsync-common/btsync-core --config//// (c) 2013-2014 BitTorrent Inc.//// This btsync configuration file features the complete set of// commented configuration directives//// DAEMON_UID=iamadmin// DAEMON_UMASK=000// DAEMON_NICE=10{ "device_name": "blabla", "listening_port" : 0, // 0 - randomize port "check_for_updates" : false, "display_new_version": false, "disk_low_priority" : true, "lan_encrypt_data" : true, "rate_limit_local_peers" : true, "folder_rescan_interval" : 86400, "folder_defaults.delete_to_trash" : true, "folder_defaults.use_dht" : false, "folder_defaults.use_lan_broadcast" : true, "folder_defaults.use_relay" : true, "folder_defaults.use_tracker" : true, "folder_defaults.known_hosts" : "", "max_file_size_for_versioning" : 2, "sync_trash_ttl" : 365, "storage_path" : "/share/.btsync", "use_upnp" : true, "download_limit" : 0, "upload_limit" : 0, "webui" : { "listen" : "192.168.0.13:8888" // remove field to disable WebUI ,"login" : "blub" ,"password" : "lalala" ,"force_https" : true // disable http ,"ssl_certificate" : "/etc/btsync/blabla.crt" ,"ssl_private_key" : "/etc/btsync/blabla.key" ,"directory_root" : "/share/" }}@RomanZ: yeah, I never measured it but 10 hours sounds about right from what I remember when it did the initial indexing. The indexings occuring on every restart only take about 2 minutes though. RAM usage of btsync is 15% according to htop, so the whole system with owncloud and btsync takes up about 250MB of RAM. Don't know how many files are in the sync folders, though. How can I find out via the ssh terminal? But according to these numbers, I don't think atte's problem are the file numbers, with half the GB it can't be much more files, if they are not all very small.

I find it really strange that your rPi cannot handle this! I keep about 350GB synchronized with btsync mostly without problems (about 7% CPU load when not syncing). That's the sum of my 8 shares, the largest of them contains around 150GB with mean file sizes of about 4MB I guess. I also have an admittedly very slow owncloud server running on the same raspberry. Have you tried restarting the btsync service or rebooting the rPi? That can work wonders sometimes If you still go for more powerful hardware, I would also recommend the BananaPi as the most direct upgrade route from the raspberry - more cpu performance + sata almost without additional cost and with raspbian support.