Эволюция файловых систем
До того, как компьютеры были разработаны для работы в дисковых операционных системах, каждый компьютер был создан для запуска одного собственного приложения, которое имело полный и эксклюзивный контроль над всем компьютером. Приложение записывает свои постоянные данные непосредственно на диск или в барабан, отправляя команды непосредственно на контроллер диска. Приложение отвечает за управление абсолютным расположением данных на диске, убедившись, что оно не перезаписывает уже существующие данные. Так как на компьютере в любое время выполнялось только одно приложение, эта задача не была слишком сложной.
Появление компьютерных систем, в которых может работать более одного приложения, требуется механизм, обеспечивающий, чтобы приложения не записывали данные друг друга. Разработчики приложений устранили эту проблему, приняв единый стандарт для различения используемых секторов диска от свободных, пометив их соответствующим образом. Со временем эти стандарты объединили в дисковую операционную систему, которая предоставляла различные службы для приложений, включая файловую систему для управления постоянным хранилищем. С появлением файловой системы приложениям больше не приходилось напрямую обращаться к физическому хранилищу. Вместо этого они просто сказали файловой системе записать блоки данных на диск и позволить файловой системе беспокоиться о том, как это сделать. Кроме того, файловая система позволяла приложениям создавать иерархии данных с помощью абстракции, известной как каталог. Каталог может содержать не только файлы, но и другие каталоги, которые, в свою очередь, могут содержать собственные файлы, каталоги и т. д.
Файловая система обеспечивала единый уровень косвенного обращения между приложениями и диском, и в результате каждое приложение видело файл как единый непрерывный поток байтов на диске, несмотря на то, что файловая система фактически хранила файл в разнородных секторах. Косвенное обращение освободило приложения от необходимости отслеживать абсолютное положение данных на запоминающем устройстве.
Сегодня практически все системные API для ввода и вывода файлов предоставляют приложения для записи информации в неструктурированный файл. Приложения видят этот файл как один поток байтов, который может увеличиваться до тех пор, пока диск не будет заполнен. В течение длительного времени этих API было достаточно для того, чтобы приложения сохраняли свои постоянные сведения. Приложения внесли значительные инновации в то, как они работают с единым потоком информации для предоставления таких функций, как добавочные "быстрые" сохранения.
Однако в мире объектов компонентов хранение данных в одном неструктурированном файле больше не является эффективным. Так же, как файловые системы возникли из-за необходимости в нескольких приложениях совместно использовать один и тот же носитель хранилища, теперь объектам компонентов требуется система, которая позволяет им совместно использовать хранилище в рамках концептуальной платформы одного файла. Несмотря на то, что отдельные объекты можно хранить с помощью обычного хранилища неструктурированных файлов, если размер одного из объектов увеличивается или просто добавляется другой объект, становится необходимо загрузить весь файл в память, вставить новый объект, а затем сохранить весь файл. Этот процесс может занять очень много времени.
Решение, предоставляемое COM, заключается в реализации второго уровня косвенного обращения: файловой системы в файле. Для хранения неструктурированных файлов требуется, чтобы большая непрерывная последовательность байтов на диске обрабатывалась с помощью одного дескриптора файла с одним указателем поиска. В отличие от этого, структурированное хранилище COM определяет, как рассматривать одну сущность файловой системы как структурированную коллекцию двух типов объектов — хранилищ и потоков , которые действуют как каталоги и файлы.