Manual sync support for 1Password
Comments
-
Your sync options are detailed in the 1Password 4 for Windows user's guide.
That link only describes how to sync between different operating systems. J23 wants to know how to sync between multiple Win 7 machines on a LAN, (without using Dropbox share).
If I remember a previous discussion correctly, the merge of two agilekeychain folders (keeping the newer item in every case of name collision) is a valid agilekeychain, so a modestly tedious and possibly error-prone manual sync could be achieved by copying and renaming and merging folders....
@J23, generally the 1Password staff will respond to this question by saying that you should use dropbox.
0 -
Syncing is syncing, @bkh—1Password itself doesn't "know" or "care" about how or even whether data is shared with other devices.
As far as 1Password is "concerned" there is only the vault (the agilekeychain or .opvault folder) on the local drive.
You cannot merge two .agilekeychain or two .opvault folders at the operating system (file system) level. You can export data from one vault (typically to 1PIF) and import it into another.
All the sync options are listed in the article I cited, but I'll add Win ←→ Win and the like for clarity, since that seems to have been a point of confusion for the two of you. Thanks for pointing that out!
0 -
You cannot merge two .agilekeychain or two .opvault folders at the operating system (file system) level.
That may be so, but the present discussion concerns independent copies of a single vault (i.e., they have the same master password): the copies have been separately updated and now we wish to sync the vault copies (merge in the differences). This topic has been discussed in another thread ( https://discussions.agilebits.com/discussion/27923/feature-request-merge-one-vault-into-another ) in which @MikeT suggests that merging at the filesystem level is actually what occurs in a Dropbox sync or Wi-Fi sync of two copies of an agilekeychain vault. (He says that it also pertains to opvaults, but I don't see how this is possible without losing one of two concurrent updates to distinct login items that happen to reside in the same one of the 16 bands.)
I think I'd better run the experiment and report back on the results.
Ok, here's what I did (using cygwin). Recall that these were two copies of the same vault on two different computers, and the contents diverged as additions and updates were made to each.
On computer 1 I did file>exit in the 1Password app and renamed 1Password.agilekeychain to 1Password_A.agilekeychain
On computer 2 I did file>exit in the 1Password app and renamed 1Password.agilekeychain to 1Password_B.agilekeychain
On a usb thumbdrive I brought the A copy of the vault to the computer containing the B copy, and put it into /cygdrive/c/users/my_username/Documents/1Password.
then
$ cd /cygdrive/c/Users/my_username/Documents/1Password $ cp -au 1Password_A.agilekeychain 1Password.agilekeychain $ cp -au 1Password_B.agilekeychain/* 1Password.agilekeychainThen I started 1Password, unlocked the vault, and saw that everything seems to be working correctly (i.e., all the logins from both A and B were present; only the newer copy of each item was there.)
I will now bring a copy of this new 1Password.agilekeychain back to the other computer, and I think this was a successful manual sync via sneakernet.
Is there some flaw in this (obviously crude) process?
0 -
The only flaw is that I've been told for over five years now that filesystem merging of .agilekeychain folders opens the risk of internal inconsistencies that render your 1Password data unusable.
I'll confirm my understanding with my co-workers, in case something has changed, but in the meantime, I would not recommend the practice you describe.
If you have two or more .agilekeychain folders with different subsets of your items, I recommend you export them from one and then import them into the others.
When any one of the .agilekeychain folders contains the complete set of items you want to maintain, you can decide whether to sync them or continue manually copying new items from one to the others every time you create them (a tedious and error-prone process that I, personally, would never choose for my own data, because syncing is automatic and dependable).
0 -
The only flaw is that I've been told for over five years now that filesystem merging of .agilekeychain folders opens the risk of internal inconsistencies that render your 1Password data unusable.
I am hoping for a more concrete explanation of the hazard, since I don't see it yet. Note that I described a static merge of stable vault copies, not concurrent live updates on a single, CIFS-mounted vault shared by multiple PCs.
0 -
Hi guys,
@bkh, we simply don't promote this as an option because if you don't know what you're doing, you can lose data such as replacing newer items with older items by accident or merging two separate data files that have different encryption keys. That's why we encourage cloud sync first as it has revision history, conflict resolution and so on. If cloud sync is not acceptable, then local sync tools that has built in support for these things such as ChronoSync on Mac. If the user is a power user that wants to use the command line, we'd go with 'rsync -E` command.
I hope you don't mind, I've split your posts out into its own thread to keep it simple for the OP.
0 -
I hope you don't mind, I've split your posts out into its own thread to keep it simple for the OP.
@MikeT, that's appropriate and a good idea.
While I've got your attention, can I ask how sync works for opvaults (say, on Dropbox)? In particular, I don't understand the merge process in the following scenario. There is a login item A and a different login item B that both reside in a single one of the 16 bands. We have concurrent updates to login A from one computer and login B from a second computer. Unlike with agilekeychains, where these updates don't collide in the filesystem, in the opvault case it seems that some kind of transactional serialization would be required, because as I understand it, Dropbox can't look inside the band to perform independent updates to A and B. So what happens? (I'm thinking about Windows where there is no local database that shadows the vault.) If the solution is considered proprietary/trade secret, just say that it works but you can't describe how.
0 -
Note that the supported sync methods are documented in the 1Password 4 for Windows user's guide.
0 -
There is a login item A and a different login item B that both reside in a single one of the 16 bands. We have concurrent updates to login A from one computer and login B from a second computer. Unlike with agilekeychains, where these updates don't collide in the filesystem, in the opvault case it seems that some kind of transactional serialization would be required, because as I understand it, Dropbox can't look inside the band to perform independent updates to A and B.
0 -
@RichardPayne, I see from your posted link that dropbox can do delta updates without completely rewriting a file. But I don't see how this helps with the scenario I posed, unless (1) within a band each login item is separately encrypted, rather than the entire band being encrypted as a unit, and (2) the storage size of a login item is fixed so there need not be some shared header with offsets to the individual login items (because the header updates would need fancy serialization to avoid losing/clobbering one of the concurrent updates). Clearly I don't understand the internals of opvault....
0 -
@bkh
Open up a band file in a text editor and you'll see the structure (you'll need to re-format the JSON as the whitespace is stripped). Each item is indeed encrypted separately.0 -
@RichardPayne, that seems promising. I only see one potential problem off the top of my head: concurrent updates to item A (adding fields or notes that cause the size of the item to grow) and physically adjacent item B. Now the two updates may modify an overlapping byte range in the result file even though they were non-overlapping in the original file. It's not clear to me that a binary diff will always be able to identify a symantically correct sequence of inserts, deletes, and updates-in-place that correctly preserve both new items. I have seen a reference in another thread to dropbox "conflict files" which suggests that there are merge scenarios that dropbox is unable to resolve.
Oops, it turns out that it's all merge scenarios: see https://www.dropbox.com/help/36 which says that dropbox never tries to merge concurrent updates. That means 1Password is required to notice the conflict files and do the merge, which is difficult to do in a completely satisfactory way. Typically one would apply the updates sequentially at the field level, ordered by timestamp, but in general this can lead to semantic-level inconsistency across fields, and unintended (at the user level) clobbers of earlier-stamped updates. Perhaps the particular semantics of the 1Password items do not suffer such problems, but that would require considerable work to verify.
But back to the original issue: to merge two diverged copies of an opvault band file manually, at the filesystem level, perhaps it suffices to rename one properly (i.e., in the way that dropbox names a conflict file) and put them into the same vault folder so that 1Password will do the merge and clean up.
0 -
@bkh at this point we need some additional information on what processing 1Password does, if any, to handle concurrent edits. @svondutch, can you enlighten us?
0
