Not showing synced changes in desktop app (but files are synced)

fatso83

I have verified that changes in my desktop changes sync instantly and show up in my mobile app. Unfortunately, the reverse is not true. That is, the changes are synced to the 1Password.agilekeys vault, but they are not shown in the desktop app. It's like a 1-way sync: it's not reading changes coming in.

I fired up a webserver (python -m SimpleHTTPServer) in the "1Password/1Password.agilekeychain" directory, and using the browser I could see the changes I had made on my mobile.

I have tried killing the mini-helper as well as the main program, and then opening 1Password afterwards. Still changes are not read.

Version 5.3.1 (531001)

Drew_AG

Hi @fatso83,

I'm sorry you're having some trouble with Dropbox sync! That's a bit strange, but I'm glad you were able to try a few things to try to narrow down the cause of the problem.

In case you haven't already seen it, please take a look at our Dropbox troubleshooting guide. If you can go through the steps/suggestions there, it should either help to solve the problem, or at least give a much clearer idea of what is causing the sync to not work in one direction.

Please let us know how that goes, and if you have any questions. Thanks!

fatso83

I found a bug in the app! Somewhere in your code you are messing up milliseconds and seconds, causing a modified time bug. I had seen the following manifestation of a bug either in 1Password or my sync solution (not Dropbox, btw): lots of files with creation date/modification date set to "Sat Jan 17 1970 14:18:23". As any programmer knows, this is a bit weird, as date errors usually manifest themselves more or less exactly around the epoch (if no time were set, it was zero, etc).

So I investigated some more, thinking it had to do with the sync solution (which it did not). I created new entries in 1Password on the desktop and they synced fine to my Android with the right date. I did the same on my Android and the file synced fine to my desktop, but with the wrong date set (Jan 17 1970). Was the sync doing this? To rule this out, I disabled sync, and created a new entry. The entry was also created with time set to Jan 17 1970, and this time the only software involved was 1Password. So the bug resides within the Android app.

I further dug some more into this: I looked into the json data, and looked at the createdAt field which was set to 1430303860. Guess what 1430303860 equates to in Unix time? No points for guessing Jan 17 1970 :-) But what does 1430303860*1000 equate to?

new Date(1430303860*1000)

Wed Apr 29 2015 12:37:40 GMT+0200 (CEST)

The current date, and the exact time the entry was modified. So I am guessing you have some kind bug. To me it looks like the Android password goes on a rampage updating files and in the process it updates the modified time of the files (but missing the seconds vs millis difference). The reason I would think so is that 119 files had their updatedAt field changed at the last sync:

$ sed -n -E 's/.*updatedAt":([0-9]+).*/\1/p' data/default/*1password|sort|grep 14303038|wc
     119     119    1309

The time stamps varied between 1430303809 and 1430303812 (a duration of 3 seconds). It goes without saying, but if it does not: I did not change anywhere near 119 passwords when I fiddled around with 1Password. I created one logon for testing.

P.S. Of course I am not totally sure this bug relates to my problem, but if the 1Password sync process is looking at the time stamp of the files, than this will explain the behaviour I am seeing!

fatso83

Hmm ... I might have been a bit hasty in my first post. Today all changes on my Android flow into the desktop version of 1Password. It just takes a few (dozens) more seconds than I expected after the sync has completed. So the original report is a non-bug, just perceived performance problems :blush:

Anyway, the modification time bug is real enough :chuffed:

rickfillion

Hi @fatso83,

Good job! I feel pretty confident in saying that you're correct in your analysis. Can I ask what version of 1Password for Android you're using? I know that they've done some pretty major work around sync lately and knowing which does this would help to know if they've already fixed this or not.

I'm going to get this information in front of the Android team and make sure that this is either already fixed in a new version or that a bug is filed in order to get this fixed.

Thanks for your hard work in diagnosing this. I love bug reports like these (despite the fact that it means we have bugs :P ).

Rick

fatso83

Good to hear, @rickfillion :chuffed: I am running 4.2.1 on my Android.

Drew_AG

Thank you @fatso83, we really appreciate all the work you put into testing and reporting this! :)

I've moved this discussion to our Android forum in case there's any follow-up for this, and you pinged Rick about the version number so he'll definitely see that. If you need anything else or find other issues, please let us know. Thanks again!

rickfillion

Hi @fatso83,

I've discussed this with the Android development team, and I'm going to go back on my "confident in saying that you're correct in your analysis".

The example timestamp value you provided as incorrect: 1430303860.
I just pulled one out of my own agilekeychain using the nice little one liner you've got there: 1414786705

My agilekeychain has never been touched by anything other than 1Password for Mac and iOS. Notice that they are not different by a factor of 1000.

If you put in your value into this epoch converter : http://www.epochconverter.com/, you'll see GMT: Wed, 29 Apr 2015 10:37:40 GMT which sounds correct.

It looks like whatever scripting language you're using there expects the parameter sent to the Date constructor to pass in milliseconds, when we're using seconds.

So it looks like 1Password for Android is in fact doing the right thing. Why those items weren't showing up instantly on your Mac is another question, but it seems like that resolved itself?

I hope this helps.

Rick

fatso83

@rickfillion No wonder you can't reproduce it, as you're mistaking what I was saying :chuffed: I'll put that on my unclear language quota :blush:

I am not saying the json data is incorrect. On the contrary, all the json values are of the same magnitude, even the old ones, so they are not in question here. The modification times of the actual file objects in the filesystem is the topic of the discussion. So what I was saying was that the part of 1Password that is using this to set the modification time (mtime) on the files seems to accept milliseconds, not seconds. That is what explains that the mtime set to Jan 17 1970, which would be equivalent of the updatedAt time divided by 1000.

I have dug some more into this and can probably point to the method name used in the Android code too :-)

On most POSIX platforms, such as Linux, you set the modification time in seconds since the epoch. An example of this is utime in the GNU C Library. On Android, on the other hand, you would probably use the standard function java.io.File#setLastModified(long time). This function expects the number of milliseconds since the epoch.

My guess is that you pass the updatedTime value (specified in seconds) directly to setLastModified without multiplying it by 1000.

P.S. As mentioned above, I am only talking about this in reference to the wrong file modification dates. The stuff I talked about in my first post was found not to be a problem - as I stated in post #4.

Dmitry_N

Hi,
I had the same issue yesterdays (both PC and Android versions being latest betas). I was only able to fix it by updating the data on one of my PCs manually.

fatso83

@Dmitry_N Which issue are you referring to, Dmitry? The discussion moved away from the original problem stated at the top to something else quite quickly. Are you seeing the file system date issue?

Dmitry_N

I am referring to this:
"the changes are synced to the 1Password.agilekeys vault, but they are not shown in the desktop app. It's like a 1-way sync: it's not reading changes coming in."

saad

Thanks for the clarification @fatso83. I will pass on this information to our Android development team and we will review how creation and modification dates are set to files using local storage sync. From my understanding so far, this issue does not affect the actual behaviour of 1Password on Android. However, it is something that needs to be resolved as it could lead certain sync solutions to misbehave.

We will be looking into correcting this. Thanks again for being very detailed with your explanation. :)

saad

@Dmitry_N Sorry to hear you are having trouble with syncing your 1Password data. :( Let's figure out what's going on.

Could you send us a diagnostic report from your Android device? It will help us get a better understanding of your 1Password configuration and device settings. Please follow these instructions to create the report and we will take a look into it.

Dmitry_N

Mail sent. With description.

saad

Thanks! :)