Overview
This document describes why having completely unique vault GUIDs is necessary.
Impacted Products and Versions
M-Files versions currently under standard support.
Symptoms
Issues in replication. Client cache issues.
Sample Case
Importing a replication packet fails. Client cache is inconsistent/corrupt.
Cause and Reason - Replication
M-Files uses several GUIDs - Globally Unique Identifiers. The word "globally" here is important - in an ideal situation, in the whole universe no two matching GUIDs exist. This is not guaranteed as the GUIDs are randomly generated but the chance of a GUID conflict is extremely rare. And even then, for it to matter, the GUID conflict would have to occur in the same type of GUID for it to matter.
When M-Files generates new objects, they receive various identifying values. These include an object GUID, object version GUID, internal object type ID and internal object ID. There are also original vault GUID, original object type ID and original object ID. The original IDs are what the values were in the vault the object was created. These original values are the same as the internal values if the object is stored in the same vault, it was created in.
When replication happens, the original IDs do not change, nor do the object and object version GUIDs but during an import procedure all the internal IDs will change since these are specific to the vault the object is stored in. So, the object being imported gets new values by the logic of the vault it is imported into.
So, let's say an object of object type 110, object ID 100 and version 1 is created in vault A. This is then replicated into vault B, both having different vault GUIDs. There it will get, for example object type 120, object ID 120 and version 1. Then if a new version of this object is created in vault B, it will be version 2. If this is replicated back to vault A, vault A can map this to the object 110-100 there and create the version 2 there. If the object had been modified also in vault A, a replication conflict would happen. But this is not within the scope of this article so let's ignore that possibility.
However, let's consider another situation. Let's assume there is vault C which has been used until the end of November. A disaster happens and the only solution is to go back to a backup taken at end of July. The backup vault is taken online with the original GUID, and the broken vault is online on another server being repaired. Let's call the restored vault D. Users begin using the restored vault D. Recovery actions are done on the vault C while vault D is being used, these two having the same GUID. Then, in February, the vault C has been recovered and data from there is attempted to be replicated to vault D, however various errors are coming out as a result.
The problem with this approach is that vault D has jumped back in time for several months. When new objects are added there, they will be receiving object IDs which exist in the vault C but the object and object version GUIDs do no match. So, let's say there is a document 0-300-1 in vault C, created in October. This did not exist in vault D (as it is from July) so eventually someone created a new document there and it got ID 0-300-1 as well. The original IDs are the same - since the vaults have the same GUID. But during replication there is an error - this is because the object and object versions GUIDs do not match. When the replication from C to D is tried, vault D receives object 0-300-1 - which already matches another object and object version in the vault D via the original ID values but the GUIDs do not match. The problem here is that an object has double identity: two objects of the same original object type, original object id and originating vault have differing object and object version GUIDs. This should not be possible.
The important matter here is that changing the GUID of a vault does not change the original vault GUID of an object. It gets the GUID the vault has then the object was created. Thus, for this recovery of having some chance of success, the vault D should have been attached with a new GUID before it was taken into use.
Similar problem can happen if a vault template is being used and vaults based on that are deployed and then at some point in time these vaults collide somehow, like via replication. Say, for example, there is a development vault E where a value list V1 is added and then this becomes production vault P1. Then, a backup of E is restored and value list V2 is added and then this becomes production vault P2. If the vaults P1 and P2 later collide - for example these value lists being replicated, there will be problems since the entries in the value lists have same ID values, but the object GUID is not a match.
Cause and Reason - Client Cache
The clients, especially the Windows Desktop client, assume that there are no two vaults with the same GUID. If the client is connected to two servers, both having a vault with the same GUID, the client cache may become corrupt.
Solution
Use always a unique GUID for every vault from the very beginning. Maintain the uniqueness under all circumstances during the lifetime of the vault. The most likely circumstances when this may be violated are restoring backups, transferring a vault to another server while the original vault is being used and then using replication to attempt to merge the changes to the new server or developing vaults using the same template. One should also note that if an M-Files vault is online, various automations can create new objects there. For example, if a workflow has any automatic state transitions based on time, new object versions may be created.
