With the explosion of personal computers in the 1980s and onward, mechanisms were introduced to combat this design flaw. And yet this is exactly the action made possible by encoding either of these pieces of immutable metadata in the file name.
As immutable metadata, both a file's type and a file's size should never change without an accompanying change to the data itself.
Regardless of whether file type or file size is encoded in the file name, the situation is the same: a piece of immutable metadata is encoded in the file name. Again, I ask you to let go of your preconceived ideas about "the way things work" and examine this example with respect to the fundamentals of metadata discussed earlier. You may be reading this now and thinking that it's ridiculous-a straw man example that is in no way analogous to file name extensions. The DOS-era reality would be files like " REPORT.294" or " EDIT.559." Years later, mixed case, long file names, reduced length restrictions, and improved representation would give us " Book Report.50K" or " Microsoft Word.15MB." Instead of file type, imagine that a different piece of immutable metadata was encoded in the file name instead of being stored separately: file size.
It may be difficult to see this as anything other than a good (or at least benign) situation if you are accustomed to it and simply accept it as "the way of things." Here's an example that may help you see this design decision in a more objective light. The removal of a dedicated storage area for file type metadata and its subsequent integration into the file name means that it is now possible to change an immutable piece of metadata (file type) by changing an independent piece of metadata (file name). Let's look at the consequences of the fateful development of what we know today as file name extensions.
0 kommentar(er)
