4 ms·

The obvious alternative is to have metadata about file in a separate descriptor, which could be saved either in first N bytes of the file, or in the file alloca

The obvious alternative is to have metadata about file in a separate descriptor, which could be saved either in first N bytes of the file, or in the file allocation table itself. However implementing this in this age would be impractical as it would break interoperability with every other (still alive) OS out there.

keketi 8y ago
> have metadata about file in a separate descriptor Maybe that metadata could be stored in the file's name, like "<filename><separator><format identifier>" or something? ducks
- deleted 8y ago
  [deleted]
msla 8y ago
> However implementing this in this age would be impractical as it would break interoperability with every other (still alive) OS out there. It's deeper than that, although this is a very good point. Who teaches the OS what file types exist? How is that updated? You could rely on the OS vendor, but that's a bottleneck, especially for a consumer-focused OS where most of the applications (and, therefore, most of the application file formats) are not created by the OS vendor, or entities working in concert with the OS vendor. You could have a great new file format and a great new application and be unable to use it, or get anyone else to use it, because the people behind the OS haven't caught up yet, or because the OS updates haven't percolated out yet. You could trust the application vendors to do it, which is a security hole: The ScuzzyTech Hyper Word Processor really, really wants to open your word processing documents, so it can synergize your monetization with microtransaction-based leveraged technologies. Therefore, all of your Normalcore Text Documents are now ScuzzyTech Hyper Word Documents only to be opened by the ScuzzyTech Hyper Word Processor, because the ScuzzyTech code helpfully updated all of your filetypes and, therefore, file associations.
marcosdumay 8y ago
I'm all for a metadata standard that would enable filetype independent fields to live and move with your data. That said, this gives you no security benefit at all. It's basically the same thing we have now, but done correctly.
JdeBP 8y ago
You and the other people in this discussion are well on the way to reinventing extended attributes, used for exactly this purpose back in the late 1980s and 1990s in OS/2.

keketi 8y ago

> have metadata about file in a separate descriptor Maybe that metadata could be stored in the file's name, like "<filename><separator><format identifier>" or something? ducks

deleted 8y ago
[deleted]

msla 8y ago

> However implementing this in this age would be impractical as it would break interoperability with every other (still alive) OS out there. It's deeper than that, although this is a very good point. Who teaches the OS what file types exist? How is that updated? You could rely on the OS vendor, but that's a bottleneck, especially for a consumer-focused OS where most of the applications (and, therefore, most of the application file formats) are not created by the OS vendor, or entities working in concert with the OS vendor. You could have a great new file format and a great new application and be unable to use it, or get anyone else to use it, because the people behind the OS haven't caught up yet, or because the OS updates haven't percolated out yet. You could trust the application vendors to do it, which is a security hole: The ScuzzyTech Hyper Word Processor really, really wants to open your word processing documents, so it can synergize your monetization with microtransaction-based leveraged technologies. Therefore, all of your Normalcore Text Documents are now ScuzzyTech Hyper Word Documents only to be opened by the ScuzzyTech Hyper Word Processor, because the ScuzzyTech code helpfully updated all of your filetypes and, therefore, file associations.

marcosdumay 8y ago

I'm all for a metadata standard that would enable filetype independent fields to live and move with your data. That said, this gives you no security benefit at all. It's basically the same thing we have now, but done correctly.

JdeBP 8y ago

You and the other people in this discussion are well on the way to reinventing extended attributes, used for exactly this purpose back in the late 1980s and 1990s in OS/2.