Créer un moteur de synchronisation cloud qui prend en charge les fichiers d’espace réservé

Un moteur de synchronisation est un service qui synchronise les fichiers, généralement entre un hôte distant et un client local. Les moteurs de synchronisation sur Windows présentent souvent ces fichiers à l’utilisateur via le système de fichiers Windows et l’Explorateur de fichiers. Avant Windows 10, version 1709, la prise en charge du moteur de synchronisation dans Windows était limitée aux surfaces ad hoc indépendantes du scénario, telles que le volet de navigation de l’Explorateur de fichiers, la barre d’état système Windows et les pilotes de filtre de système de fichiers (pour plus d’applications techniques).

Windows 10 version 1709 (également appelée Fall Creators Update) a introduit l’API fichiers cloud. Cette API est une nouvelle plateforme qui formalise la prise en charge des moteurs de synchronisation. L’API fichiers cloud prend en charge les moteurs de synchronisation d’une manière qui offre de nombreux nouveaux avantages aux développeurs et aux utilisateurs finaux.

L’API fichiers cloud contient les API Win32 natives suivantes et les API Windows Runtime (WinRT) :

• API de filtre cloud : cette API Win32 native fournit des fonctionnalités au niveau de la limite entre le mode utilisateur et le système de fichiers. Cette API gère la création et la gestion des fichiers et répertoires d’espace réservé.
• Espace de noms Windows.Storage.Provider : cette API WinRT permet aux applications de configurer le fournisseur de stockage cloud et d’enregistrer la racine de synchronisation auprès du système d’exploitation.

Remarque

L’API fichiers cloud ne prend actuellement pas en charge l’implémentation de moteurs de synchronisation cloud dans les applications UWP. Les moteurs de synchronisation cloud doivent être implémentés dans les applications de bureau.

Fonctionnalités prises en charge

L’API fichiers cloud fournit les fonctionnalités suivantes pour la création de moteurs de synchronisation cloud.

Fichiers d’espace réservé

• Les moteurs de synchronisation peuvent créer des fichiers d’espace réservé qui consomment seulement 1 Ko de stockage pour l’en-tête du système de fichiers et qui s’hydratent automatiquement dans des fichiers complets dans des conditions d’utilisation normales. Les fichiers d'espace réservé semblent être des fichiers classiques dans le Windows Shell, pour les applications et les utilisateurs finaux.
• Les fichiers d’espace réservé sont intégrés verticalement à partir du noyau Windows jusqu’à Windows Shell, et la compatibilité des applications avec les fichiers d’espace réservé est généralement un non-problème. Que vous utilisiez les API de système de fichiers, l’invite de commandes, une application de bureau ou une application UWP pour accéder à un fichier d’espace réservé, le fichier s’hydratera sans modifications de code supplémentaires et l’application peut utiliser le fichier normalement.
• Les fichiers peuvent exister dans trois états :
  • Fichier d’espace réservé : représentation vide du fichier et disponible uniquement si le service de synchronisation est disponible.
  • Fichier complet : le fichier a été hydraté implicitement et peut être déshydraté par le système si l’espace est nécessaire.
  • Fichier complet épinglé : le fichier a été hydraté explicitement par l'utilisateur via l'Explorateur de fichiers et est assuré d'être disponible hors connexion.

L’image suivante montre comment les états de fichier de remplacement, complet et épinglé sont affichés dans l’Explorateur de fichiers.

Enregistrement standardisé de la racine de synchronisation

• L’inscription d’une racine de synchronisation est simple et standardisée. Cela inclut la création d’un nœud de marque dans le volet de navigation de l’Explorateur de fichiers, comme illustré dans la capture d’écran suivante. Les racines peuvent être créées en tant qu’entrées individuelles de niveau supérieur ou en tant qu’enfants d’un regroupement parent.

  

Intégration de shell

• Icônes d’état :
  • L’API fichiers cloud fournit des icônes d’état d’hydratation automatiques standardisées affichées dans l’Explorateur de fichiers et sur le bureau Windows.
  • Outre les icônes d’état Windows standard utilisées pour l’état d’hydratation, vous pouvez fournir des icônes d’état personnalisées pour des propriétés supplémentaires spécifiques au service.
  • Remplace les anciennes extensions Shell de superposition d'icônes.
• Indication de progression :
  • L’ouverture d’un fichier de type espace réservé qui prend plus de quelques secondes à s'hydrater affichera la progression de l’hydratation. La progression s’affiche à quelques emplacements en fonction du contexte :
    • Dans une fenêtre de boîte de dialogue du moteur de copie.
    • La progression inline s’affiche en regard du fichier dans l’Explorateur de fichiers.
    • Si le fichier n’est pas ouvert à l’instruction spécifique de l’utilisateur, une notification toast s’affiche pour informer l’utilisateur et fournir un moyen de contrôler l’activité d’hydratation involontaire.
• Miniatures et métadonnées :
  • Les fichiers temporaires peuvent avoir de riches miniatures fournies par le service et des métadonnées de fichier étendues pour offrir à l’utilisateur une expérience transparente de l’Explorateur de fichiers.
• Volet de navigation de l’Explorateur de fichiers :
  • L’inscription d’une racine de synchronisation avec l’API fichiers cloud entraîne l’affichage de la racine de synchronisation (avec une icône et un nom personnalisé) dans le volet de navigation de l’Explorateur de fichiers.
• Menus contextuels de l’Explorateur de fichiers :
  • L’inscription d’une racine de synchronisation avec l’API fichiers cloud fournit automatiquement plusieurs verbes (entrées de menu) dans le menu contextuel de l’Explorateur de fichiers qui permettent à l’utilisateur de contrôler l’état d’hydratation de son fichier.
  • Des verbes supplémentaires peuvent être ajoutés à cette section du menu contextuel à l’aide des API compatibles avec desktop Bridge.
• Contrôle utilisateur de l’hydratation des fichiers :
  • Les utilisateurs contrôlent toujours l’hydratation des fichiers, même si les fichiers ne sont pas hydratés explicitement par l’utilisateur. Un toast interactif s’affiche pour l’hydratation en arrière-plan pour alerter l’utilisateur et fournir des options. L’image suivante illustre une notification toast pour un fichier d’hydratage.
  • Si un utilisateur empêche une application d'hydrater les fichiers par le biais d'une notification interactive, il peut débloquer l'application dans la page Téléchargements automatiques de fichiers de Paramètres.
• Accrochage des opérations du moteur de copie (pris en charge dans Windows 10 Insider Preview Build 19624 et versions ultérieures) :
  • Les fournisseurs de stockage cloud peuvent inscrire un hook de copie shell pour surveiller les opérations sur les fichiers au sein de leur racine de synchronisation.
  • Le fournisseur inscrit son hook de copie en définissant la valeur de Registre CopyHook sous sa clé de Registre racine de synchronisation sur le CLSID de son objet serveur local COM. Cet objet serveur local implémente l’interface IStorageProviderCopyHook .
• Partage de fichiers (pris en charge dans Windows 11 version 21H2 et versions ultérieures) :
  • Les fournisseurs de stockage cloud peuvent inscrire un gestionnaire de partage qui sera appelé lorsque l’utilisateur sélectionne la commande « Partager » sur un fichier cloud sous sa racine de synchronisation.
  • Le fournisseur inscrit son gestionnaire de partage en définissant la valeur de Registre ShareHandler sous sa clé de Registre racine de synchronisation sur le CLSID de son objet serveur local COM. Cet objet serveur local implémente l’interface IExplorerCommand .

Passerelle de l'ordinateur de bureau

• Les moteurs de synchronisation utilisant les API de fichiers cloud sont conçus pour utiliser Desktop Bridge comme exigence d’implémentation.

Exemple de Miroir de Nuage

L’exemple Cloud Mirror montre comment créer une solution qui utilise l’API fichiers cloud. Il n’est pas destiné à être utilisé comme code de production. Il n’a pas de gestion des erreurs robuste et il est écrit pour être aussi facilement compris que possible. Il est appelé Cloud Mirror, car il met simplement en miroir un dossier local sur votre disque local. Vous spécifiez un dossier de serveur destiné à représenter votre serveur de fichiers cloud et un dossier client destiné à spécifier le chemin racine de synchronisation. Un nœud de niveau supérieur apparaît dans le volet de navigation de l’Explorateur de fichiers appelé TestStorageProviderDisplayName, et ce nœud est mappé au dossier client spécifié.

En ce qui concerne la synchronisation, il s’agit des éléments que doit implémenter un fournisseur de synchronisation de fichiers cloud entièrement développé :

• Lorsque le fichier racine de synchronisation n’est qu’un espace réservé, le service est responsable de la copie du contenu du fichier pour l’hydratation. Cette opération est implémentée dans l’exemple.
• Lorsque le fichier racine de synchronisation est un fichier complet et que le contenu du fichier dans le service cloud change, le service est chargé de notifier le client de synchronisation local de la modification et le client de synchronisation local doit gérer les fusions en fonction de leurs propres spécifications. Cela n’est pas implémenté dans l’exemple.
• Lorsque le fichier racine de synchronisation est un fichier complet et que le contenu du fichier dans le chemin racine de synchronisation (le client local) change, le client de synchronisation local doit notifier le service cloud et gérer les fusions en fonction de leurs propres spécifications. La notification de modification de fichier local est implémentée dans l’exemple, mais elle ne fait rien.

Utiliser l’exemple

1. Créez deux dossiers sur votre disque dur local. L’un d’eux agit comme le serveur et l’autre en tant que client.
2. Ajoutez certains fichiers au dossier du serveur. Vérifiez que le dossier client est vide.
3. Ouvrez l’exemple Cloud Mirror dans Visual Studio. Définissez le projet CloudMirrorPackage comme projet de démarrage, puis générez et exécutez l’exemple. Lorsque vous y êtes invité par l’exemple, entrez les deux chemins d’accès à vos dossiers serveur et client. Une fois cette opération terminée, une fenêtre de console s’affiche avec des informations de diagnostic.
4. Ouvrez l’Explorateur de fichiers et vérifiez que vous voyez le nœud TestStorageProviderDisplayName et les espaces réservés pour tous les fichiers que vous avez copiés dans le dossier du serveur. Pour simuler une application qui tente d’ouvrir des fichiers sans utiliser le sélecteur, copiez plusieurs images dans le dossier du serveur. Double-cliquez sur l’un d’entre eux dans votre dossier racine de synchronisation et vérifiez qu’il s’hydrate. Ensuite, ouvrez l’application Photos. L'application précharge les fichiers adjacents en arrière-plan afin de réduire le risque que l’utilisateur subisse des retards lors de la navigation à travers les autres images. Vous pouvez observer la déshydratation des fichiers en arrière-plan via des notifications contextuelles ou dans l’Explorateur de fichiers.
5. Cliquez avec le bouton droit sur un fichier dans l’Explorateur de fichiers pour afficher un menu contextuel, puis vérifiez que vous voyez l’élément de menu TestCommand . Cliquez sur cet élément de menu pour afficher une boîte de message.
6. Pour arrêter l’exemple, définissez le focus sur la sortie de la console et appuyez sur Ctrl-C. Cela nettoie l'enregistrement racine de synchronisation pour permettre la désinstallation du fournisseur. Si l’exemple se bloque, il est possible que la racine de synchronisation reste inscrite. Cela entraîne le redémarrage de l’Explorateur de fichiers chaque fois que vous cliquez sur n’importe quoi, et vous serez invité à entrer les emplacements faux du client et du serveur. Si cela se produit, désinstallez l’exemple d’application CloudMirrorPackage à partir de votre ordinateur.

Exemple d’architecture

L’échantillon est délibérément simple. Il utilise des classes statiques pour qu’il soit inutile de passer des pointeurs d’instance. Voici les classes principales de l’exemple :

• FakeCloudProvider : cette classe de niveau supérieur contrôle les classes worker suivantes :
  • CloudProviderRegistrar : inscrit les informations racines de synchronisation auprès de Windows Shell.
  • Fichiers de substitution : génère les fichiers de substitution dans le chemin racine de synchronisation.
  • ShellServices : construit les fournisseurs Windows Shell pour le menu contextuel, les miniatures et d’autres services.
  • CloudProviderSyncRootWatcher : instancie un DirectoryWatcher pour surveiller les modifications apportées au chemin racine de synchronisation et agir sur les modifications.
  • FileCopierWithProgress : copie les fichiers du dossier serveur vers le dossier client lentement en blocs pour simuler le téléchargement à partir d’un serveur cloud réel. Fournit une indication de progression pour que les toasts et l'interface utilisateur de l'Explorateur de fichiers affichent des informations utiles à l'utilisateur.

En plus des classes ci-dessus, l’exemple fournit également plusieurs classes d’assistance pour inviter l’utilisateur à entrer des dossiers et certains utilitaires. TestExplorerCommandHandler, CustomStateProvider, ThumbnailProvider et UriSource sont tous des exemples de fournisseurs de services Shell.

Architecture de l’API de fichiers cloud

Au cœur de la pile de stockage de l'API de fichiers en nuage se trouve un pilote mini-filtre du système de fichiers appelé cldflt.sys. Ce pilote agit en tant que proxy entre les applications de l’utilisateur et votre moteur de synchronisation. Votre moteur de synchronisation sait comment télécharger et charger les données à la demande alors qu’il incombe à cldflt.sys de travailler avec l’interpréteur de commandes pour présenter des fichiers comme si les données cloud étaient disponibles localement.

actuellement, Cldflt.sys prend uniquement en charge les volumes NTFS, car cela dépend de certaines fonctionnalités propres à NTFS.

Il existe de nombreux pilotes minifilter de système de fichiers dans un système et peuvent être actifs sur un volume donné en même temps. Les pilotes qui intéressent le plus l’API de fichiers cloud sont les filtres antivirus du système de fichiers.

Les pilotes minifilter du système de fichiers sont gérés et pris en charge par un composant spécial en mode noyau appelé gestionnaire de filtres. Parmi de nombreuses autres tâches, le gestionnaire de filtres facilite la communication non filtrée entre les filtres et les composants en mode utilisateur via une construction appelée port de message de filtre.

Stratégies d’hydratation

Windows prend en charge une variété de stratégies d’hydratation principales et de modificateurs de stratégie d’hydratation secondaire . Les stratégies d’hydratation principales ont cet ordre :

Toujours plein > Complet > Progressif > Partiel

Les applications et les moteurs de synchronisation peuvent définir leur stratégie d’hydratation principale préférée. Si elle n’est pas spécifiée, la stratégie d’hydratation par défaut est progressive pour les applications et les moteurs de synchronisation.

La stratégie d’hydratation d’un fichier cloud est déterminée au moment de l’ouverture du fichier par cette formule :

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

Par exemple, supposons que l’utilisateur tente d’ouvrir un fichier PDF stocké sur Fabrikam Cloud Drive à l’aide de Contoso PDF Viewer, qui ne spécifie pas de stratégie d’hydratation préférée. La stratégie d’hydratation de l’application est donc une hydratation progressive, dans ce cas par défaut. Toutefois, étant donné que Fabrikam Cloud Drive est un moteur de synchronisation à hydratation complète, la stratégie finale d’hydratation sur le fichier devient une hydratation complète, ce qui entraînera la totale hydratation du fichier lors du premier accès. Le même résultat se produit dans les cas où le moteur de synchronisation prend en charge l'hydratation progressive, mais la préférence de l'application est l'hydratation complète.

Notez que la stratégie d’hydratation de fichier ne peut pas être modifiée après l’ouverture du fichier.

Compatibilité avec les applications qui utilisent des points de réanalyse

L’API fichiers cloud implémente le système d’espace réservé à l’aide de points d’analyse. Une idée fausse courante sur les points de réanalyse est qu'ils sont les mêmes que les liens symboliques. Cette idée fausse est parfois reflétée dans les implémentations d’applications, et par conséquent, de nombreuses applications existantes rencontrent des erreurs lors de la rencontre d’un point de réanalyse.

Pour atténuer ce problème de compatibilité, l’API fichiers cloud masque toujours ses points de réanalyse de toutes les applications, à l’exception des moteurs de synchronisation et des processus dont le fichier principal réside sous %systemroot%. Les applications qui comprennent les points de retraitement correctement peuvent forcer la plateforme à exposer des points de l'API des fichiers de cloud à l’aide de RtlSetProcessPlaceholderCompatibilityMode ou RtlSetThreadProcessPlaceholderCompatibilityMode.

Recherche dans les fichiers cloud

La recherche de fichiers cloud est prise en charge dans Windows 11, version 24H2 et ultérieures sur les PC Copilot+. Les fonctionnalités suivantes sont disponibles pour les fournisseurs de stockage cloud à intégrer à l’expérience Windows Search :

• Les fournisseurs de stockage cloud peuvent inscrire un gestionnaire de recherche de fichiers pour leur racine de synchronisation, ce qui leur permet de contribuer aux résultats de recherche à l’Explorateur de fichiers et à La Recherche Windows.
• Les fournisseurs de stockage cloud inscrivent un gestionnaire de recherche en définissant la valeur de Registre SearchHandlerFactory sur le CLSID de leur objet serveur local COM, sous leur clé de Registre de synchronisation principale. Cet objet serveur local implémente l’interface IStorageProviderSearchHandlerFactory .
• IStorageProviderSearchHandlerFactory crée une implémentation de IStorageProviderSearchHandler. Cette implémentation IStorageProviderSearchHandler appelle le service de recherche du fournisseur de cloud pour rechercher des fichiers qui peuvent ne pas être disponibles localement sur l’appareil.
• L’expérience Windows Search appelle la méthode Find pendant une recherche, en fusionnant ses résultats avec ceux de l’indexeur de recherche local.

Contenu connexe

Intégration du fournisseur de fichiers cloud à Windows Search

IStorageProviderSearchHandlerFactory

Espace de noms Windows.Storage.Provider