When a new password is set on the id in a vault and the user logs in with the new password on a machine, where an old id is used, the old id is move to \SaveIDS\user.@.ID, i.e. user.2008_09_11@22_51_46.IDThe new ID is stored as \user.id.
Ergo, the sync mechanism does not change the password on the existing ID, but does exchange the ID files.
Subject: Only if the second ID file never sync’d with the vault…
If the second copy of the ID file was already “vaulted”, then the new password would successfully authenticate to the vault (but not unlock the local ID file). The local ID would be shipped up to the vault server, which could then unlock the client’s copy of the ID file, merge it with the vault copy of the ID, then return the merged result to the client, which would then re-encrypt the ID under the new password.
The only time that the old ID will be copied off to the saved IDs directory is when that old ID file had never synchronized with the vault, and so the vault was unable to unlock that ID file. In that case, a copy of the vault’s ID is returned to the client, and the client stashes away the old ID file to avoid potential loss of data.
But even in that case, one can log into the old ID with the old password and change the password to match the vault password. That ID will then sync up with the vault and behave as expected in the future.
Subject: Bug in beta code
The beta release always saved the current ID file in SavedIDs. This has been corrected for the final release.