RomanZ

@eltopo I've got a bit more information about this issue. Please take a glance at ".sync" subfolder. I wonder, if: a) it contains the .db files at all sync has enough permissions to write there as this error sometimes popup when SQLite can't create DB files at all.

@wimbit It actually indicates that app crashes. We receive app crash reports via google play and fix it. If you want some "quick fix" - most likely app reinstallation is going to help you as it removes and creates DB from scratch.

@pjank I managed to reproduce issue in the lab - and it looks to be a bug. For now you can use the single-component form as a workaround while we do fix the issue. Thanks for reporting.

@wimbit Do I understand correctly that when it closes - you see your Android desktop? Or it simply turns off the screen?

@mumen It's not an issue - file attributes are not transferred intentionally, this is the app design. The only attribute that is synchronize by Sync is "execute" attr for Linux OS.

@Bitwise It asks once per notification it wants to show. Is it a VM? If yes - can I get the image for repro? Issue does not reproduce in my lab.

@Ravidlow Just capture it with any means (even making a picture / video on your cellphone will work) and send to me.

@Mrath The 4Gb file size limitation is known issue for Android phones. It is bound to Android API and the max file size it reports to requesting apps.

@mll That's right. The copy @GreatMarko advised will work fine only if you are moving from old PC to a new one. It won't work if you _clone_ Sync as it clones PeerID and identity. While identity clone is not going to cause big trouble, non-unique PeerID is going to. The most simple way to force Sync to re-create it is delete settings.dat and settings.dat.old file. Though, it will reset all your peer global settings as well.

@eazq Well, Sync IS case sensitive while Windows filesystems are not. Current solution is not the most elegant indeed - we are aware of it and eventually will implement a better solution.

@Bitwise Memory consumption increases accordingly. If you have your send buffer 5 megs and increase it to 50, Sync will consume 45 megs more.

@pjmsullivan Yes, the issue for negative "locked files" issue is known and is purely cosmetic. We'll fix it in future - please ignore for now. @mh5bl If you have SSH access to your NAS - it's rather easy. List the processes running (ps aux | grep btsync), see which config file was supplied to sync process, open it and add / modify "sync_trash_ttl" option. This option is not available for Android version of Sync (and actually no files are archived on mobile versions of Sync). @Journeyman Yeah, we know of this UI issue. Thanks for bringing to our attention. As workaround you can expand window width.

@mhadjimichael There are a number of events that can bring the "old files overwrite new ones". I suggest checking if any could happen in your environment recently: - Sync is killed unexpectedly / crashed. DB in this case is not saved properly. - file was modified simultaneously on 2 peers, while Sync was off on one of them (also applies to Sync-for-Android's "Auto-sleep" mode). - File has mtime from future.

@Ravidlow (1) is a bug. I confirm reproduction in Lab - it will be fixed in future releases. Thanks for pointing to it. (2) This one is design. You can't change from RW to RO. (A) The target computer has no idea, if Link requires to be approved or not (this info is intentionally not included in Link as it can be transferred via insecure means). It understands that no approval needed only at the moment it actually contacts the Link owner peer. ( Can you plz provide a screenshot?

@mh5bl Indeed, there are some issues with app preferences during upgrade from 1.3 to 1.4. I'll check if it reproduces in lab.

@nunu, @sciurius, Can you please turn on your debug logs and send to me? 2 peers affected logs are necessary, if you know exactly the name of file that is not syncing - it will ease log analysis. Thanks!

@eltopo The error is not good. It indicates that the Sync's database got corrupt and Sync cannot save data there effectively. The most straightforward way to fix it is to remove sync folder and add it again, though it does not gives any advise on how it happened. SQLite doc advises some possible reasons, so couple of questions to clarify: 1) Where Sync's storage is located? Anything special (external drive, NFS)? 2) What is the FS of volume where Sync storage is located? How is it mounted? As for the "incoming connection" - it can't be removed from the log, though it should not be an issue: logs rotation is set to around 10Mb by default, so it should never grow over 20Mb (counting sync.log.old backup).

@Qlex Usually this indicates the fact that there is some connectivity issue between RPI and other devices. Please check that these ports are not blocked in your network. If this does not help - I'll need a bit more information: How are they connected? Same LAN? Wired, wireless? Any specific folder preferences?

@acffordyce973 1) Can you please try to shut down sync and try clicking link again? 2) If it does not help - please try to convert whole link to QR code (there are a plenty of websites) and try to scan it with Sync and see if it will work

@Bitwise It doesn't look to be BTSync issue. We just ask OS to show notification ballon and how long to show it (10 seconds in Sync case), the rest is handled by OS. Just note that balloon timeout starts to be counted down only when you press a key / move a mouse. BTW, are you using any remote administration tool? They might emulate mouse movements / keystrokes differently.

@pumpapa So, did you manage to fix it by setting proper ownership?

@demani It would be okay, though it will take some time to index all the files and make sure they are the same as on RW peers.

@pjmsullivan I don't see a screenshot - it says lack of permissions. Can you please share it in other way? @Lion Try looking into the peer list and see if these files are there.

@ninja6o4 It would be simpler if you mail me with issue description - we'll instruct you on which debugs to collect.

@b0rman Sync caches peers and remembers their local can global IPs. Try setting peer_expiration days to "0" advanced preference and restart your client - it should flush cache of peers.