Old Files Synced Over New Files From Android

[Scribulations]

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.

[RomanZ]

@Scribulations

Let me clarify couple of things. Please confirm / clarify the following:

 

1. You got some folder synced between Debian, W10, W7, Android.

2. You have a keepass DB there.

3. You copied the newest DB on Android to sync folder.

4. New DB (one in sync folder) did not propagate to your home Windows PC

5. New DB (one in sync folder) was replaced with old one from PC.

 

Is this correct?

[Scribulations]

 

1. You got some folder synced between Debian, W10, W7, Android.

2. You have a keepass DB there.

Correct

 

3. You copied the newest DB on Android to sync folder.

4. New DB (one in sync folder) did not propagate to your home Windows PC

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.

 

 

New DB (one in sync folder) was replaced with old one from PC.

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:

1. Created a new share on my computer.
2. Added a new keypass db with a dummy entry in it.
3. Synced the new share with my Android phone and set it to auto-sync.
4. Shut down Sync on my phone.
5. Added two new entries to the Keypass DB on my computer.
6. Added an image file to my shared folder on my phone.
7. 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

[RomanZ]

Bradley,

 

One more question to clarify your case. Did the keypass KDB file changed on your Android device AFTER you shut down Sync on Android? Even the very tiny change (even changing mtime) is counted.

[jsbeddow]

I can confirm that I have seen this exact same behaviour when sycning keypass files between Windows computers running 1.4.103 and Android mobile version 1.4.63: the older file versions on the Andriod frequently get "updated" onto the Windows machines, when I know that the newer version infactc exists on the Windows machine, resulting in lost data in the keepass files.  This is manually repairable by resorting to backups in the archive folder (or elsewhere) but a real pain to keep track of.

 

Please clarify the above info about minor changes on Android (mtime???) : does this mean that the android file system will always automatically "refresh/update" the file date/time stamp after simply opening a file, even without making any "real" changes to it?  This would explain this disastrous behaviour.  Perhaps keepass does this when simply performing a search on the database (it might consider this an update of where in the database to open to, upon next opening).  Any workarounds?

[RomanZ]

@jsbeddow

No, Android FS (usually Ext3/ext4) could update the "access time", not the "mtime" unless the file is changed. Though, it also depends on keepass behavior - it might actually write some data into DB even if no actual change was done. In any case, you give me a good hint on issue reproduciton - I'll attempt another repro in the lab, thanks.

[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

[RomanZ]

Bradley,

 

Thanks for info - please keep me updated.

[jsbeddow]

Bradley,

 

Sadly, I have come to the same conclusions as you: there seems to be no consistant reason or noticable behaviour on the part of keepass that would lead to this.  I have also checked to see if any filestamp time changes (on the keepass file) after simply opening it and performing a search, but as far as I can tell, it does not rewrite the timestamp.  There are, however, some options within keepass (android) that might bear investigating: under "Settings", "Application", then "File Handling", perhaps someone might be able to determine if the "Database caching", "Check for modifications", or "File transactions" settings have any effect on this.

 

Keep us all posted...thanks.