Stato cache nella radice di virtualizzazione

Il provider usa il file system locale nella radice di virtualizzazione come cache degli elementi gestiti. Un elemento (file o directory) può trovarsi in uno dei sei stati nel file system locale:

  • Le macchine

    L'elemento non esiste in locale sul disco. Viene proiettato, ovvero sintetizzato, durante le enumerazioni della directory padre. Gli elementi virtuali vengono uniti a tutti gli elementi che possono esistere su disco per presentare il contenuto completo della directory padre.

  • Segnaposto

    Per i file: il contenuto del file (flusso di dati primario) non è presente sul disco. I metadati del file (nome, dimensioni, timestamp, attributi e così via) vengono memorizzati nella cache sul disco.

    Per le directory: alcuni o tutti i discendenti immediati della directory (i file e le directory nella directory) non sono presenti sul disco, ad esempio sono ancora virtuali. I metadati della directory (nome, timestamp, attributi e così via) vengono memorizzati nella cache sul disco.

  • Segnaposto idratato

    Per i file: il contenuto e i metadati del file sono stati memorizzati nella cache sul disco. Detto anche "file parziale".

    Per le directory: una directory creata su disco come segnaposto non diventa mai una directory segnaposto idratata. In questo modo il provider può aggiungere o rimuovere elementi dalla directory nel relativo archivio di backup e fare in modo che tali modifiche vengano riflesse nella cache locale.

  • Segnaposto sporco (idratato o meno)

    I metadati dell'elemento sono stati modificati localmente e non sono più una cache dello stato nell'archivio del provider. Si noti che la creazione o l'eliminazione di un file o di una directory in una directory segnaposto fa sì che la directory segnaposto diventi dirty.

  • File/directory completo

    Per i file: il contenuto del file (flusso di dati primario) è stato modificato. Il file non è più una cache dello stato nell'archivio del provider. Anche i file creati nel file system locale (ovvero che non esistono nell'archivio del provider) vengono considerati file completi.

    Per le directory: le directory create nel file system locale ,ovvero che non esistono nell'archivio del provider, vengono considerate directory complete. Una directory creata su disco come segnaposto non diventa mai una directory completa.

  • Tombstone

    Segnaposto nascosto speciale che rappresenta un elemento eliminato dal file system locale. Quando una directory viene enumerata ProjFS unisce il set di elementi locali (segnaposto, file completi e così via) con il set di elementi proiettati virtuali. Se un elemento viene visualizzato sia nei set locali che nei set proiettati, l'elemento locale ha la precedenza. Se un file non esiste nel file system locale, non esiste alcuno stato locale, quindi viene visualizzato nell'enumerazione . Tuttavia, se tale elemento è stato eliminato, la visualizzazione nell'enumerazione sarebbe imprevista. La sostituzione di un elemento eliminato con una rimozione definitiva comporta gli effetti seguenti:

    • Enumerazioni per non visualizzare l'elemento.
    • Il file viene aperto che prevede che l'elemento esista non riesce, ad esempio "file non trovato".
    • Il file crea l'esito positivo solo se l'elemento non esiste correttamente; ProjFS rimuove la pietra definitiva come parte dell'operazione.

Per illustrare gli stati precedenti, prendere in considerazione la sequenza seguente, dato un provider ProjFS con un singolo file "foo.txt" che si trova nella radice di virtualizzazione C:\root.

  1. Un'app enumera C:\root. Viene visualizzato il file virtuale "foo.txt". Poiché il file non è ancora stato eseguito, il file non esiste su disco.
  2. L'app apre un handle per C:\root\foo.txt. ProjFS indica al provider di creare un segnaposto.
  3. L'app legge il contenuto del file. Il provider fornisce il contenuto del file a ProjFS e viene memorizzato nella cache in C:\root\foo.txt. Il file è ora un segnaposto idratato.
  4. L'app aggiorna il timestamp dell'ultima modifica. Il file è ora un segnaposto idratato sporco.
  5. L'app apre un handle per l'accesso in scrittura al file. C:\root\foo.txt è ora un file completo.
  6. L'app elimina C:\root\foo.txt. ProjFS sostituisce il file con una rimozione definitiva. Ora quando l'app enumera C:\root non viene visualizzata foo.txt. Se tenta di aprire il file, l'apertura ha esito negativo con ERROR_FILE_NOT_FOUND.