Scribulations

RomanZ, From a user's perspective the file was not saved or altered so the modified time should not have changed. That being said, I can't speak for anything that the KeePassDroid app actually did in the background when the database was open. It could very well have updated some meta data or re-saved the entire database without my knowledge. The problem hasn't arisen again since, however, I have only used it twice on my phone since the issue originally occurred. I've checked the modified time in ES File Explorer and it is dated to before the times I've accessed it. Also, from my previous tests I wasn't able to reproduce the same error state where the old KeePass database was being pushed to the swarm so if it is KeePass updating the database in the background, which it is feeling more and more likely considering jsbeddow's confirmation of the issue being related to KeePass, it isn't doing it consistently which is more then a little bit of a pain as far as debugging goes. I'll keep poking it on my phone and checking the modified time to see if I can catch KeePassDroid fiddling with the file behind my back and keep you posted. Bradley

Correct Not exactly. Sync hadn't been running on my phone for at least a week in which time I had added more entries to my keepass DB on my other computers in the swarm. Between my Windows 7, Windows 10 and Debian machines these changes synced fine. The problem arose when I added another file to the share (I did not update keepass database) on my phone. I noticed sync wasn't running on my phone and started it. It started syncing and I let it go. Later when I opened my keypass file on my Windows 10 machine I noticed it had rolled back. I checked the old version in the .sync folder and it was the version that had been previously there the night before which was more up to date. It is probably important to note at this point on my Windows 10 machine the state of the share had changed to "out of sync" which it was not prior to me updating the share on my phone. No. The Keypass Database from my phone (which was old and out of date) was pushed to the swarm and updated the version on the Windows 10 machine (and probably the others, however, I didn't check them and just restored them via a backup). ----- Updates: I was running the current beta version of 1.4 on my Windows 10 machine. I also attempted to reproduce the error but couldn't. Here are the steps I attempted: Created a new share on my computer. Added a new keypass db with a dummy entry in it. Synced the new share with my Android phone and set it to auto-sync. Shut down Sync on my phone. Added two new entries to the Keypass DB on my computer. Added an image file to my shared folder on my phone. Turned on Sync.The results were what you would expect. The image was synced to my computer and the Keypass DB was synced to my phone... So there might be something else at play, perhaps an incorrect time stamp attached to the Keypass DB or a corrupted check sum which led sync to think the Keepass DB was newer on the phone. Bradley

Effected Machines: Android 4.4 BTSync Version: 1.4.63.0 Windows 10 BTSync Version: 1.4.? (I'll have to check the specific version when I get home) Overview of the issue: I have been using BTSync with few issues for quite a while between my work machine (Debian Testing), my home machines (Windows 10 and Windows 7) and my phone (Android 4.4). However this morning I copied a file to my a sync folder on my phone. I then noticed sync wasn't running (likely due to a restart at some point a week or more previous). I started up the Sync application and it notified me it was re-indexing that specific share and then proceeded to the sending state. Thinking all is well I checked my computer before heading to work and opened up my keepass file, which I keep synced so I have access to it on all my devices. I then noticed that the recent entries were missing from it which had been there the night before. It would seem that the Android client pushed its old version of that file to my peer network and I would assume other files in that share as well. The issue didn't really hurt me since, after learning my lesson several times, I have rsync do a nightly backup of all my files on my work machine but the issue remains and makes me very hesitant to continue relying on BitTorrent Sync. PS: I couldn't find a bug tracker for this so I assume this is the best place to report the bug.