Creare un motore di sincronizzazione cloud che supporti i file segnaposto

Un motore di sincronizzazione è un servizio che sincronizza i file, in genere tra un host remoto e un client locale. I motori di sincronizzazione in Windows spesso presentano tali file all'utente tramite il file system di Windows e Esplora file. Prima di Windows 10, versione 1709, il supporto del motore di sincronizzazione in Windows era limitato alle superfici ad hoc indipendenti dallo scenario, ad esempio il riquadro di spostamento di Esplora file, la barra delle applicazioni windows e (per altre applicazioni tecniche) driver di filtro del file system.

Windows 10 versione 1709 (chiamata anche Fall Creators Update) ha introdotto l'API dei file cloud. Questa API è una nuova piattaforma che formalizza il supporto per i motori di sincronizzazione. L'API dei file cloud offre il supporto per i motori di sincronizzazione in modo da offrire molti nuovi vantaggi agli sviluppatori e agli utenti finali.

L'API dei file cloud contiene le API Win32 native e le API Windows Runtime (WinRT):

• API filtro cloud: questa API Win32 nativa fornisce funzionalità al limite tra la modalità utente e il file system. Questa API gestisce la creazione e la gestione dei file segnaposto e delle directory.
• Finestre. Archiviazione. Spazio dei nomi del provider: questa API WinRT consente alle applicazioni di configurare il provider di archiviazione cloud e registrare la radice di sincronizzazione con il sistema operativo.

Nota

L'API dei file cloud attualmente non supporta l'implementazione dei motori di sincronizzazione cloud nelle app UWP. I motori di sincronizzazione cloud devono essere implementati nelle app desktop.

Funzionalità supportate

L'API dei file cloud offre le funzionalità seguenti per la creazione di motori di sincronizzazione cloud.

File segnaposto

• I motori di sincronizzazione possono creare file segnaposto che utilizzano solo 1 KB di spazio di archiviazione per l'intestazione del file system e che si idratano automaticamente in file completi in condizioni di utilizzo normali. I file segnaposto presenti come file tipici per le app e per gli utenti finali nella shell di Windows.
• I file segnaposto sono integrati verticalmente dal kernel di Windows fino alla shell di Windows e la compatibilità delle app con i file segnaposto è in genere un problema non. Sia che usi le API del file system, il prompt dei comandi o un desktop o un'app UWP per accedere a un file segnaposto, il file verrà idratato senza modifiche di codice aggiuntive e tale app può usare normalmente il file.
• I file possono esistere in tre stati:
  • File segnaposto: rappresentazione vuota del file e disponibile solo se il servizio di sincronizzazione è disponibile.
  • File completo: il file è stato idratato in modo implicito e potrebbe essere disidratato dal sistema se è necessario spazio.
  • File completo aggiunto: il file è stato idratato in modo esplicito dall'utente tramite Esplora file ed è garantito che sia disponibile offline.

L'immagine seguente illustra come vengono visualizzati gli stati dei file completi, completi e aggiunti in Esplora file.

Registrazione radice sincronizzazione standardizzata

• La registrazione di una radice di sincronizzazione è semplice e standardizzata. Ciò include la creazione di un nodo con marchio nel riquadro di spostamento di Esplora file, come illustrato nello screenshot seguente. Le radici possono essere create come singole voci di primo livello o come elementi figlio di un raggruppamento padre.

  

Integrazione della shell

• Icone di stato:
  • L'API dei file cloud fornisce icone di stato di idratazione standardizzate e automatiche visualizzate in Esplora file e sul desktop di Windows.
  • Oltre alle icone di stato standard di Windows usate per lo stato di idratazione, è possibile fornire icone di stato personalizzate per proprietà aggiuntive specifiche del servizio.
  • Sostituisce le estensioni della shell di sovrapposizione dell'icona legacy.
• Indicazione dello stato di avanzamento:
  • L'apertura di un file segnaposto che richiede più di pochi secondi per idratare mostrerà lo stato di idratazione. Lo stato di avanzamento viene visualizzato in alcune posizioni a seconda del contesto:
    • In una finestra di dialogo del motore di copia.
    • Lo stato inline viene visualizzato accanto al file in Esplora file.
    • Se il file non viene aperto all'istruzione specifica dell'utente, viene visualizzata una notifica di tipo avviso popup per informare l'utente e fornire un modo per controllare l'attività di idratazione imprevista.
• Anteprime e metadati:
  • I file segnaposto possono avere anteprime avanzate fornite dal servizio e metadati di file estesi per offrire all'utente un'esperienza di Esplora file senza problemi.
• Esplora file riquadro di spostamento:
  • La registrazione di una radice di sincronizzazione con l'API dei file cloud fa sì che la radice di sincronizzazione (con un'icona e un nome personalizzato) venga visualizzata nel riquadro di spostamento di Esplora file.
• Esplora file menu di scelta rapida:
  • La registrazione di una radice di sincronizzazione con l'API dei file cloud fornisce automaticamente diversi verbi (voci di menu) nel menu di scelta rapida di Esplora file che consentono all'utente di controllare lo stato di idratazione del file.
  • È possibile aggiungere verbi aggiuntivi a questa sezione del menu di scelta rapida usando le API compatibili con Desktop Bridge.
• Controllo utente dell'idratazione dei file:
  • Gli utenti sono sempre in controllo dell'idratazione dei file, anche quando i file non vengono idratati in modo esplicito dall'utente. Viene visualizzato un avviso popup interattivo per l'idratazione dello sfondo per avvisare l'utente e fornire opzioni. L'immagine seguente illustra una notifica di tipo avviso popup per un file di idratazione.
  • Se un utente impedisce a un'app di idratare i file tramite un avviso popup interattivo, può sbloccare l'app nella pagina Download automatici dei file in Impostazioni.
• Hooking delle operazioni del motore di copia (supportato in Windows 10 Insider Preview Build 19624 e versioni successive):
  • I provider di archiviazione cloud possono registrare un hook di copia della shell per il monitoraggio delle operazioni dei file all'interno della radice di sincronizzazione.
  • Il provider registra l'hook di copia impostando il valore del Registro di sistema CopyHook nella chiave del Registro di sistema radice di sincronizzazione sul CLSID dell'oggetto server locale COM. Questo oggetto server locale implementa l'interfaccia I Archiviazione ProviderCopyHook.
• Condivisione file (supportata in Windows 11 versione 21H2 e versioni successive):
  • I provider di archiviazione cloud possono registrare un gestore di condivisione che verrà richiamato quando l'utente seleziona il comando "Condividi" in un file cloud nella radice di sincronizzazione.
  • Il provider registra il gestore di condivisione impostando il valore del Registro di sistema ShareHandler nella chiave del Registro di sistema radice di sincronizzazione sul CLSID dell'oggetto server locale COM. Questo oggetto server locale implementa l'interfaccia IExplorerCommand .

Desktop Bridge

• I motori di sincronizzazione che usano le API dei file cloud sono progettati per usare Desktop Bridge come requisito di implementazione.

Esempio di cloud mirror

L'esempio cloud mirror illustra come creare una soluzione che usa l'API dei file cloud. Non deve essere usato come codice di produzione. Non dispone di una gestione degli errori affidabile e viene scritta per essere più facilmente comprensibile possibile. Si chiama Cloud Mirror perché esegue semplicemente il mirroring di una cartella locale sul disco locale. Si specifica una cartella server destinata a rappresentare il file server cloud e una cartella client destinata a specificare il percorso radice di sincronizzazione. Un nodo di primo livello viene visualizzato nel riquadro di spostamento in Esplora file denominato Test Archiviazione ProviderDisplayName e questo nodo esegue il mapping alla cartella client specificata.

Per quanto riguarda la sincronizzazione, questi sono gli elementi che un provider di sincronizzazione dei file cloud completamente sviluppato deve implementare:

• Quando il file radice di sincronizzazione è solo un segnaposto, il servizio è responsabile della copia del contenuto del file per l'idratazione. Questa operazione viene implementata nell'esempio.
• Quando il file radice di sincronizzazione è un file completo e il contenuto del file nel servizio cloud cambia, il servizio è responsabile della notifica al client di sincronizzazione locale della modifica e il client di sincronizzazione locale deve gestire le unioni in base alle specifiche specifiche. Questa operazione non viene implementata nell'esempio.
• Quando il file radice di sincronizzazione è un file completo e il contenuto del file nel percorso radice di sincronizzazione (il client locale) cambia, il client di sincronizzazione locale deve inviare una notifica al servizio cloud e gestire le unioni in base alle specifiche specifiche. La notifica di modifica del file locale viene implementata nell'esempio, ma non esegue alcuna operazione.

Usare l'esempio

1. Creare due cartelle sul disco rigido locale. Uno di essi fungerà da server e l'altro come client.
2. Aggiungere alcuni file alla cartella del server. Assicurarsi che la cartella client sia vuota.
3. Aprire l'esempio Cloud Mirror in Visual Studio. Impostare il progetto CloudMirrorPackage come progetto di avvio e quindi compilare ed eseguire l'esempio. Quando richiesto dall'esempio, immettere i due percorsi delle cartelle server e client. Dopo questa operazione verrà visualizzata una finestra della console con informazioni di diagnostica.
4. Aprire Esplora file e verificare di visualizzare il nodo Test Archiviazione ProviderDisplayName e i segnaposto per tutti i file copiati nella cartella del server. Per simulare un'applicazione che tenta di aprire file senza usare la selezione, copiare diverse immagini nella cartella del server. Fare doppio clic su uno di essi nella cartella radice di sincronizzazione e verificare che idrata. Aprire quindi l'app Foto. L'app pre-carica i file adiacenti in background per renderlo più probabile che l'utente non verifichi ritardi durante la ricerca delle altre immagini. È possibile osservare la disidratazione in background avviene tramite toast o in Esplora file.
5. Fare clic con il pulsante destro del mouse su un file in Esplora file per visualizzare un menu di scelta rapida e verificare che venga visualizzata la voce di menu TestCommand. Facendo clic su questa voce di menu verrà visualizzata una finestra di messaggio.
6. Per arrestare l'esempio, impostare lo stato attivo sull'output della console e premere CTRL+C. In questo modo verrà eseguita la pulizia della registrazione radice di sincronizzazione in modo che il provider venga disinstallato. Se l'esempio si arresta in modo anomalo, è possibile che la radice di sincronizzazione rimanga registrata. In questo modo Esplora file riavviare ogni volta che si fa clic su qualsiasi elemento e si riceverà una richiesta per le posizioni di client e server falsi. In questo caso, disinstallare l'applicazione di esempio CloudMirrorPackage dal computer.

Architettura di esempio

L'esempio è deliberatamente semplice. Usa classi statiche per rendere non necessario passare puntatori all'istanza. Di seguito sono riportate le classi principali dell'esempio:

• FakeCloudProvider: questa classe di primo livello controlla le classi di lavoro seguenti:
  • CloudProviderRegistrar: registra le informazioni radice di sincronizzazione con La shell di Windows.
  • Segnaposto: genera i file segnaposto nel percorso radice di sincronizzazione.
  • ShellServices: costruisce i provider della shell di Windows per il menu di scelta rapida, le anteprime e altri servizi.
  • CloudProviderSyncRootWatcher: crea un'istanza di DirectoryWatcher per monitorare le modifiche al percorso radice di sincronizzazione e agire sulle modifiche.
  • FileCopierWithProgress: copia i file dalla cartella del server alla cartella client lentamente in blocchi per simulare il download da un server cloud reale. Fornisce indicazioni sullo stato di avanzamento in modo che gli avvisi popup e Esplora file'interfaccia utente mostrino all'utente qualcosa di informativo.

Oltre alle classi precedenti, l'esempio fornisce anche diverse classi helper per richiedere all'utente cartelle e alcune utilità. TestExplorerCommandHandler, CustomStateProvider, ThumbnailProvider e UriSource sono tutti esempi di provider di servizi Shell.

Architettura dell'API file cloud

Al centro dello stack di archiviazione nell'API dei file cloud è un driver minifiltro del file system denominato cldflt.sys. Questo driver funge da proxy tra le applicazioni dell'utente e il motore di sincronizzazione. Il motore di sincronizzazione sa come scaricare e caricare i dati su richiesta, mentre è responsabilità di cldflt.sys usare Shell per presentare i file come se i dati cloud fossero disponibili in locale.

Cldflt.sys supporta attualmente solo i volumi NTFS perché dipende da alcune funzionalità univoche per NTFS.

Esistono molti driver minifiltri del file system in un sistema e possono essere attivi contemporaneamente in un determinato volume. I driver di maggiore interesse per l'API dei file cloud sono i filtri del file system antivirus.

I driver minifiltri del file system sono gestiti e supportati da un componente speciale in modalità kernel denominato gestione filtri. Tra gli altri compiti, gestione filtri facilita la comunicazione non filtrata tra filtri e componenti in modalità utente tramite un costrutto noto come porta del messaggio di filtro.

Criteri di idratazione

Windows supporta un'ampia gamma di criteri di idratazione primari e modificatori di criteri di idratazione secondari. I criteri di idratazione primari hanno questo ordine:

Completa sempre completa >> parziale progressiva >

Sia le applicazioni che i motori di sincronizzazione possono definire i criteri di idratazione primari preferiti. Se non specificato, il criterio di idratazione predefinito è progressivo sia per le applicazioni che per i motori di sincronizzazione.

I criteri di idratazione di un file cloud vengono determinati all'ora di apertura del file in base alla formula seguente:

File hydration policy = max(app hydration policy, provider hydration policy)

Si supponga, ad esempio, che l'utente stia tentando di aprire un file PDF archiviato in Fabrikam Cloud Drive usando Contoso PDF Viewer, che non specifica un criterio di idratazione preferito. Il criterio di idratazione dell'applicazione è quindi l'idratazione progressiva, in questo caso per impostazione predefinita. Tuttavia, poiché Fabrikam Cloud Drive è un motore di sincronizzazione dell'idratazione completo, il criterio di idratazione finale sul file diventa completamente idratato, che comporterà l'idratazione completa del file al primo accesso. Lo stesso risultato si verifica nei casi in cui il motore di sincronizzazione supporta l'idratazione progressiva, ma la preferenza dell'app è l'idratazione completa.

Si noti che i criteri di idratazione dei file non possono essere modificati dopo l'apertura del file.

Compatibilità con le applicazioni che usano reparse points

L'API dei file cloud implementa il sistema segnaposto usando reparse points. Un malinteso comune sui punti di riferimento è che sono uguali a collegamenti simbolici. Questo malinteso si riflette occasionalmente nelle implementazioni dell'applicazione e, di conseguenza, molte applicazioni esistenti riscontrano errori durante l'incontro di qualsiasi punto di analisi.

Per attenuare questo problema di compatibilità, l'API dei file cloud nasconde sempre i relativi punti di analisi da tutte le applicazioni, ad eccezione dei motori di sincronizzazione e dei processi la cui immagine principale risiede in %systemroot%. Le applicazioni che conoscono correttamente i reparse point possono forzare la piattaforma a esporre i punti di reparse dell'API dei file cloud usando RtlSetProcessPlaceholderCompatibilityMode o RtlSetThreadProcessPlaceholderCompatibilityMode.