RomanZ

@kevork Sync stores its service files in next locations: 1) "storage folder" stores DBs, your keys, certificates, etc. You can find location of storage folder here for various OSes, see paragraph #3 2) in every synced folder there is a hidden subfolder ".sync". It contains folder-specific data. As Sync crashes, the issue is very likely in storage folder - and it needs to be cleaned up. The only folder(s) I can recommend to leave there would be "sync-v1-backup-#######" as it is backup of your storage folder of 1.4 version.

Steve, Note that it may happen due to fact that other instances of Sync request for some data (or provide a new data to your Sync). If you are confident they do not transfer data and all the measures on preventing wake up are applied - I'll help you in debugging your case.

@sebijisi Indeed, there is some issue in processing large amount of small files by Sync - and they can affect data transfer speed significantly. The sqlite DB is not a bottleneck here. We plan to optimize it in future. For the TCP connections instead of UDP ones - there is a debug flag which you can set to force Sync to use TCP to connect. Although note, that UDP is much more flexible in establishing direct connection, so forcing TCP may result in inability to directly connect in some cases. So, to force TCP-only - create a debug.txt file in storage folder (see this article for possible locations depending on OS) - put the value of "00000000<newline>00000002" into this file - save file, restart Sync. Do on all peers involved. Disclaimer (to everyone who did not read the warning above) Use with care. May cause inability to connect peers directly. Let me know if it helped to improve your syncing speed.

@uffowich Got the logs, thanks. And - huge thanks to you for collecting logs on latest 2.0.93!

@alin The freebsd issue will be fixed in next update. @andrewb It is true for both 1.4 and 2.0 folders.

@andi-at Sync moves files to archive only when other peers indicate that files were removed. What other peers do you have? Any specific events happened there before you noticed files were moved to archive? Are you using on-demand sync or sync-all mode for the folder affected? Also, files from archive are deleted only by 1 of 2 events: 1. File is too old (moved to archive 30 days ago) 2. File is big (Sync stores only one version of a file it is bigger than ~1Gb) Also, if you have several peers - its worth checking their archives too. I would really like to help you with this issue. If you are willing to debug it - please collect debug log (it always contains some data) as well as all .journal files from the same folder.

@fardok It more depends on your usage rather than amount of Sync instances. Briefly, if you use your cloud of Sync for your personal needs - it is considered to be a personal usage. If you are using it to run your business or work, or something alike - it will be business use. If you provide some services to other people with Sync and charge money for it - it would be commercial use.

@Steve Glad to hear! You also might want to create "debug.txt" in storage folder and put "00000000" there to prevent Sync from writing logs, which also might wake up your NAS HDD.

@fardok 1. The forum topic for 1.4 Sync also contains latest 1.4 APK for android. Feel free to use. 2. 2.0 supports config file same way as 1.4 did, also folders can be configured to not to use internet. Please elaborate your question. 3. As @wweich mentioned, Sync 2.0 (even free version) supports "keys like in 1.4". All you need to do is to hold shift when clicking "Add folder button" - and Sync will generate key. See this article or just search KB for the "classic" keyword.

@jdrch Could you please share the precise step-by-step scenario? I tried it in the lab with no success: upon folder disconnection Android version of Sync warns that no files are going to be removed and actually does not remove them.

@yidengchn The 1.4.111 is the most fixed "out-of-sync version", although it is still missing 2 fixes that are present in 2.0 (and can't be back-ported). "Out-of-sync" issue has a number of different root causes, which end with the same result: Sync does not transfer data between peers. We've managed to identify around 4-5 different root causes and all of them were addressed in 2.0. So, we hope that users won't suffer from this issue anymore. Actually, I don't understand what is so annoying in downgrade. At the end of day, all you need to do is to restore Sync 1.4's service data and install old 1.4 Sync. The 1.3->1.4 downgrade was not possible at all! There is no intentionally plante bugs in Sync. The "out-of-sync" issue was present since early release versions (even pre 1.0), it just had a different name - people were complaining on "Sync stuck" and "Data not transferring" or "It shows data for upload and nothing changes". The folder statuses introduced in 1.4 just gave a convenient name which could be utilized for the same issue that goes since 0.x releases.

Hi 2d, Sync does not lock files or open for exclusive use. Although, if some other application will attempt to open the file for exclusive use, OS will reject such a request as it is already open by Sync. Sync distinguishes deleted and locked files, so it shouldn't be the reason. If you still have the environement running - I'll be happy to take a look at your debug logs and ".journal" files. We can also try to reproduce it in our lab if you let me know your VMWare Workstation version.

@colinabroad, @looker zeng The license is granted to a person (see EULA). So if one is using 20 devices alone - he is okay to proceed with one license. Although, if he got 2 users using these 20 devices - he'll need 2 licenses.

@kevork Sure, you are welcome!

@all, @kramttocs Although "My devices" uses sync folder to propagate your folders, it uses different mechanism of cleanup and "peer_expiration_days" won't affect it. We are aware of the issue with cleaning up duplicates or devices that will never appear there again - and we plan to address it in future builds. @hcjl You cannot delete your files remotely - as they will move into Archive instead of actual removing. You cannot remove remote device from "My devices" mesh, so you'll need to re-generate your identity, add all folders from scratch on new identity and link all your other devices to this new identity. If there are some 1.4 folders - re-add them manually to regenerate keys.

@all, Indeed, there is 1 item missing in the instructions list - we'll fix it. I apologize for inconvenience. @kevork If it is still relevant - you can go to %appdata%\BitTorrent Sync, delete all files there (Sync should be off, of course) and copy there files that were in sync-v1-backup-#######. During uninstallation on Windows - you need to check the checkbox "Also remove settings". During uninstallation on Mac you'll need to delete ~/Library/Application Support/BitTorrent Sync @colinabroad There were a wide number of complains from users during 1.3 - 1.4 migration who requested us for the downgrade path - so we provided it in 2.0. Note, that "remove all an configure from scratch" will always work. Actually, a wide variety of applications leave their data on PC when uninstalling - in case the data can be reused later. Some of them do it silently, some - let user know that data is still there and can be used. Sync proposes to remove data during uninstallation process to give user more control over its disk space.

@Moe Not exactly. The Tracker server tells everyone how and where to find peers. Relay server actually transfers data. Although, Relay server is just a backup plan for the case when peers can't establish direct connection. It is really slow comparing to direct connection. @skycryer While relay server cannot see any data bypassing as it is encrypted, there is still a way to ensure your folders are not using relay server. Just open your folder preferences and uncheck "Use relay server" option.

@harrisc Hmm. I wonder if you can try to open your Sync WebUI from other browser, say Firefox? You can do it from other computer, although you'll need to run your Sync on RPI with "--webui.listen 0.0.0.0:8888" switch to force it to bind socket to all interfaces (it listens loopback only by default).

@colinabroad There is no point in getting 1.4 logs for this issue. The related code changed way too much in 2.0. @sciurius Sync 1.4 is capable on processing limited amount of OS "file change" events per time unit. This issue was discovered in support thanks to the user who did exactly same scenario you describe: moved files with rsync. I can't tell you precise limits as they depend on OS itself and how quickly it floods Sync with events. Although, it was addressed in 2.0 and shouldn't be an issue anymore.

@harrisc I wonder if you can send me JS console output from the browser which opens RPI webui? Thanks!

@el_milagro I beg you pardon, seems I confused 2 scenarios. @proactiveservices is right - you need only files to pre-seed ERO peer. The scenario I was thinking about is restoring your data from ERO peer only (imagine that all other peers are dead or do not have data). In this case, you'll need files on ERO peer AND storage folder content AND RW key.

@all, Please see topic started - we've updated glibc2.3 version of Sync.

@0xDEADC0DE The license is granted to the user. So one identity is one user and you'll need as many licenses as many users are going to use Sync.

@boydshermis Let me know if there is something I can help you with. @Windlasher We are aware of this request already - the "UI for excluding files" was requested a number of times in the past.

@josh4trunks Only one change - new preference "Config_save_interval" (was actually introduced in latest 1.4 builds) which allows to tweak Sync behavior and let HDD sleep if no activity happens. See here for full list.