Evoluzione dei file system
Prima che i computer siano stati sviluppati per funzionare nei sistemi operativi su disco, ogni computer è stato creato per eseguire una singola applicazione proprietaria, che aveva il controllo completo ed esclusivo dell'intera macchina. L'applicazione scriverà i dati persistenti direttamente in un disco o un batterio inviando comandi direttamente al controller del disco. L'applicazione è stata responsabile della gestione dei percorsi assoluti dei dati sul disco, assicurandosi che non fosse sovrascrivendo i dati già esistenti. Poiché solo un'applicazione è in esecuzione nel computer in qualsiasi momento, questa attività non era troppo difficile.
L'avvento dei sistemi computer che potevano essere eseguiti più di un'applicazione richiedeva un meccanismo per garantire che le applicazioni non scrivessero i dati degli altri. Gli sviluppatori di applicazioni hanno risolto questo problema adottando un unico standard per distinguere i settori del disco in uso da quelli liberi contrassegnandoli di conseguenza. In tempo, questi standard si sono uniti per diventare un sistema operativo su disco, che ha fornito vari servizi alle applicazioni, incluso un file system per la gestione dell'archiviazione persistente. Con l'avvento di un file system, le applicazioni non avevano più a che fare direttamente con il supporto di archiviazione fisica. Invece, hanno semplicemente detto al file system di scrivere blocchi di dati nel disco e lasciare che il file system si preoccupi di come farlo. Inoltre, il file system ha consentito alle applicazioni di creare gerarchie di dati tramite un'astrazione nota come directory. Una directory potrebbe contenere non solo file ma altre directory, che a sua volta potrebbero contenere i propri file e directory e così via.
Il file system ha fornito un singolo livello di indiretto tra le applicazioni e il disco e il risultato è che ogni applicazione ha visto un file come un singolo flusso contiguo di byte sul disco anche se il file system archiviava effettivamente il file in settori discontigui. L'indiretto libera le applicazioni dalla necessità di tenere traccia della posizione assoluta dei dati in un dispositivo di archiviazione.
Attualmente, tutte le API di sistema per l'input e l'output del file forniscono applicazioni per la scrittura di informazioni in un file flat. Le applicazioni visualizzano questo file come singolo flusso di byte che possono crescere al massimo fino a quando il disco non è pieno. Per molto tempo queste API sono state sufficienti per le applicazioni per archiviare le informazioni persistenti. Le applicazioni hanno apportato innovazioni significative nel modo in cui gestiscono un singolo flusso di informazioni per fornire funzionalità come i salvataggi "veloci" incrementali.
Tuttavia, in un mondo di oggetti componente, l'archiviazione dei dati in un singolo file flat non è più efficiente. Così come i file system hanno necessità di condividere più applicazioni nello stesso supporto di archiviazione, quindi, ora, gli oggetti componente richiedono un sistema che consente loro di condividere l'archiviazione all'interno del framework concettuale di un singolo file. Anche se è possibile archiviare gli oggetti separati usando l'archiviazione di file flat convenzionale, se uno degli oggetti aumenta di dimensioni o se si aggiunge semplicemente un altro oggetto, diventa necessario caricare l'intero file in memoria, inserire il nuovo oggetto e quindi salvare l'intero file. Questo processo può richiedere molto tempo.
La soluzione fornita da COM consiste nell'implementare un secondo livello di indiretto: un file system all'interno di un file. L'archiviazione file flat richiede che una sequenza contigua di byte sul disco venga modificata tramite un singolo handle di file con un singolo puntatore di ricerca. Al contrario, l'archiviazione strutturata COM definisce come trattare un'entità di file system singola come una raccolta strutturata di due tipi di oggetti, archiviazioni e flussi, che fungono da directory e file.