Change Of Program Logic For R/o Nodes' File Modification

[stanha]

Well, it seems that the experiment of compensating for the file modifications, deletions and renaming on r/o nodes has failed in the most profound ways.

Not because someone is "stupid" and could not conceive of a better way of assuring what seemed to be a good intent in the initial phases, but because it is logically unresolvable. So, essentially it was an effort to resolve unresolvable.

Because once the r/o node is user modified, such as deletion, modification or renaming of files, it immediately becomes inconsistent with the reference view of the r/w nodes.

So, the principle of "user knows better" does not really work, especially if we consider the fact that user may decide to modify, delete or rename some file not even realizing what are going to be the effects.

Therefore, "to make a long story short", it is proposed to get away from the idea of "user knows better" and introducing the different logic in the r/o nodes for the cases where user modifies, deletes or renames some files.

The basic idea is simple: the ONLY nodes that "dictate" the state of the nodes are the r/w nodes, or the r/o nodes that fully comply with the state of the r/w nodes.

That means, if file is deleted on the r/o nodes and it does exist on either r/w nodes or compliant r/o nodes, that file will be restored, that is redownloaded from the r/w nodes or compliant r/o nodes.

The same thing is applicable to all other modifications of the file, such as editing or renaming.

So, the logic becomes simple: If you want to CHANGE something, make a copy of a file you want to modify and do not rename it back to its original name because it will be overwritten by the r/w nodes. Otherwise, the database across the nodes becomes inconsistent.

The files that were renamed on the r/o nodes will be simply re-downloaded from the reference (r/w or compliant r/o) nodes. For the files that were modified, the modifications will be lost, simply because they make that file inconsistent with the reference view of the r/w nodes. Therefore, if you wish to modify some file, you must rename it. It can not have the same name as a file that exists on the r/w node. Because it will make your node inconsistent with the state of the r/w node and no logic will be able to resolve that inconsistency simply because it does not know your intent, and ever if it did, the user itself might not realize what are going to be the consequences of those modifications in terms of the state of consistency across all nodes.

The rest you can figure out. But the "bottom line" is that logic becomes simple and predictable and there is no difference in behavior between r/w nodes and r/o nodes, at least for the most part of it. But further analysis will be required.