hpcc-systems/HPCC-Platform — Issue #1359: Property Access Control et al
Author: rengolin
Created: 2012-01-26 17:02:11+00:00
State: open

File properties are public things. You can ```queryProperties``` and have direct RW access to all of the file's attributes.

Internal to DFS, this is used by SuperFiles, SubFiles, FileParts to change their state and the state of their peers and children, but that opened an avenue of coupling that extends far beyond DFS's arena. One such example is Thor. Today, I was investigating a rogue file write (in ```thorlcr/activities/thdiskbase.cpp``` while investigating #622) and found that the methods are writing directly to the properties, without the use of ```lockProperties``` (which is not enforced), nor making sure it gets persisted or is actually correct.

My proposal is simple: Close external access to any file property, enforce getter and setters that can validate each and every change, and can also enforce they're within a lock/unlock section, if necessary.

This has several draw-backs, and the biggest by far is that it'll stiff property-changing code (such as Thor's disk read/write). While there may have some added bureaucracy, the lower coupling and increased coherency will, IMHO, make the code much more maintainable.

Another benefit is that it'll be clear, then, which properties are in use and which are not. Today, there is no way to know what is being written to the properties, since anyone can write anything to it.

Also, in Debug mode, we could add a ```dump()``` method in such access control, so you can dump the contents of the property tree in a debugger (like GDB) and inspect what's changing and what's not. In Release mode we could turn this dump into a read-only tree that the IDE can inspect to display information to the users, if needed.

This access control is not restricted to files and the DFS, it could be used by anything that uses property trees.