GreatMarko

@kbahrami, no this thread isn't closed - closed threads are locked, cannot be replied to, and are denoted with a padlock icon in the thread list. In relation to your question - .!sync files are essentially incomplete transfers - they're "placeholders" for incoming data. Once a file has been fully received, it is automatically renamed to have its .!sync extension removed. The persistence of .!sync files indicate that transfers were not completed. To resolve, exit Sync on all your devices, manually remove any .!sync files, and restart Sync on your devices. This will prompt Sync to restart the transfer of these "stuck" files.

Have you tried running BTSync.exe with the "/webui" command line switch? This will open Sync's interface in your default browser, rather than in its own window - and so could be used to determine whether it was just the windowed interface that was "not responding", or the Sync engine itself. Also, you mention you're syncing 6 folders - what is the combined size/number of files across these 6 folders? Usually sluggish performance/temporary "hangs" of the UI have been due to Sync loading/indexing a massive amount/size of files at startup.

Try /home/pi/.config/btsync/btsync.conf You can also generate a sample config file by running sync with the "--dump-sample-config" paramter. In relation to "decreasing performance" - do you mean decreasing performance of Sync/increasing performance of your system, or increasing the performance of Sync/decreasing the performance of your system? Either way, here are some of the key advanced settings which can affect performance of Sync/your system: disk_low_priority - set to "true" will concede resources to other applications accessing storage lan_encrypt_data - setting this to "true" can increase CPU load folder_rescan_interval - setting this too low will increase the rate of storage access and which can in turn reduce performance of your system recv_buf_size/send_buf_size - the higher these values, the more memory will be consumed by Sync Also, if you're syncing folders with using encrypted keys, this can also increase the CPU usage of Sync.

If you're sure both devices are using full-access (Read/Write) keys and you're experiencing "out of sync" issues, there are a couple of things you can check: 1) That the contents of .sync/IgnoreList is identical on both devices 2) That none of the files in the folder you're syncing are currently open/locked/in use by other applications

.!sync files are temporary "placeholders" for incoming files. Once all the data has been received for a file, it is automatically renamed to have its .!sync extension removed. Basically, .!sync files are incomplete transfers. If you have persistent .!sync files, it may be that Sync has got stuck. To resolve, exit sync on all your devices, delete any .!sync files, and restart Sync. This will force Sync to restart those "stuck" transfers

Unfortunately, at present, the Sync iOS app needs to be running and in the foreground for syncing to occur. The developers are aware of this limitation and are hoping to address it in a future update.

Sync can't sync files whilst they are open/locked/in use by other applications. Outlook's .PST files are an example of this, therefore, Sync will only be able to sync these files when Outlook isn't running

Not at present - consider adding your suggestion to the Feature Request forum

Are you using full access keys, or read-only keys across your 3 devices?

To my knowledge, there haven't really been similar reports of 1.4.103 using significantly more CPU/RAM than earlier builds - so, some things to check: Have you added more folders to Sync/are you syncing more files than you were previously? - The more files being monitored by Sync, the higher the memory usage. Are you using any encrypted keys, or are syncing any encrypted files/drives/containers? The following settings can also be tweaked to provide optimal performance for your system: Setting "lan_encrypt_data" to "false" can help reduce CPU usage Setting "disk_low_priority" to "true" can reduce CPU usage Increasing the sizes of "recv_buf_size" and "send_buf_size" can reduce CPU usage at the expense of increased Memory usage. Increasing the sizes of "recv_buf_size" and "send_buf_size" can reduce Memory usage at the expense of increased CPU usage.

Sync can't sync files whilst they're open/locked/in use by other applications - so check that you've not got your photos open in any other application(s) Also, ensure that there is sufficient free space on your other devices to receive files from your iPhone device

When sync_trash_ttl is set to "0" it means "keep forever". Please see this article.

1) Make sure the file has actually downloaded (synced) to your iOS device 2) Open it with Excel Notes: - If your iOS device only has a Read-Only key for the folder containing your Excel document, changes you make to it on your iOS device won't propagate to other devices - The folder containing your Excel document may not be set to "Sync all" on your iOS device, meaning that it will display in the file list within Sync but may not have actually downloaded (which will need to happen before you can open/edit it)

Indeed - "selective sync" (which has be present in the mobile editions of Sync for some time) will becoming to desktop versions for Sync 2.0. This will allow you to sync specific files within a folder, rather than the entire folder contents.

The speed of indexing can depend on a number of factors including the number of files to be indexed, the speed of your CPU, available memory... but what's interesting is that you mention a 20GB Trucrypt volume. Do you get the same slow indexing performance if you try with a 20GB folder that's isn't a Trucrypt volume? In relation to "out of sync" - you've not mentioned if the devices you're syncing with are all using full access Sync keys (Read/Write), or read-only keys? If it's the latter, you may need to select the "Overwrite any changed files" option on your read-only nodes to bring them back into sync with read/write nodes

At possible, it is only possible to disable/enable (i.e. pause) Sync globally. There is a thread in the Feature Request forum for "selective pause" i.e. being able to pause folders individually - you may wish to contribute to that thread and add in your desire to be further able to pause only upstream/downstream syncing.

@box0220 - this is a very old thread - the last post was over 15 months ago, and a lot has happened since then! "secrets" as they were in earlier versions of Sync are now know as "keys" in Sync 1.4

@groovybug - this thread was only started two weeks ago, so yes, it's still in development! @all, please bear in mind with it being Christmas/New Year, responses from the Sync team in the forums may be a little slower than usual. I will however give Richard a nudge!

OK. Do you have Tracker/Relay/DHT options enabled? (these are also per-folder settings) - If so, disabling these would further reduce traffic on your network.

The "Search LAN" option puts additional multicast traffic on your local network - that's likely why your network mouse is "sluggish" when Sync is running. Pre-defined hosts should work without "Search LAN" being enabled - if they don't it's likely they're not correct - are PC1 and PC on fixed IP addresses? Have you specified the Port that Sync is running on each device in your pre-defined hosts lists?

See: Alt Streams and Xattrs in Sync

Sync uses base32 strings and ED25519 and SHA3 cryptographic algorithms for Key generation. Please see this article.

Why not just enable debug logging?

Folks, you may be interested to know that "selective sync" is coming in Sync 2.0, and that it is now in open alpha and available for community testing! For more 2.0 information, download links, documentation and discussions, please refer to the dedicated Sync 2.0 forums.

Folks, Sync 2.0 is now in open alpha and available for community testing! For more information, download links, documentation and discussions, please refer to the dedicated Sync 2.0 forums. IMPORTANT - PLEASE READ: Sync 2.0 is currently in alphaAlpha builds should not be used with "mission critical" data and are presented for testing and evaluation purposes only so that the team can gain valuable insight into how the new features are being used in the real world as well as any issues that need to be addressed prior to public launch.Alpha builds will expire on February 16, 2015