Créer un moteur de synchronisation de 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 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 d’Explorateur de fichiers, la barre système Windows et, pour les applications plus techniques, des pilotes de filtre de système de fichiers.

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

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

• API de filtre cloud : cette API Win32 native fournit des fonctionnalités à 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.Stockage.Provider : cette API WinRT permet aux applications de configurer le fournisseur de stockage cloud et d’inscrire la racine de synchronisation auprès du système d’exploitation.

Fonctionnalités prises en charge

L’API de 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 uniquement 1 Ko de stockage pour l’en-tête du filesystem, et qui se sérialisent automatiquement dans des fichiers complets dans des conditions d’utilisation normales. Les fichiers d’espace réservé se présentent sous forme de fichiers classiques pour les applications et les utilisateurs finaux dans Windows Shell.
• 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 faux problème. Que vous utilisiez des API de système de fichiers, une invite de commandes ou une application de bureau ou UWP pour accéder à un fichier d’espace réservé, le fichier se sérialise sans modifications de code supplémentaires et cette application peut utiliser le fichier normalement.
• Les fichiers peuvent exister dans trois états :
  • Fichier d’espace réservé : une représentation vide du fichier et disponible uniquement si le service de synchronisation est disponible.
  • Fichier complet : le fichier a été sérialisé implicitement et peut être désérialisé par le système si de l’espace est nécessaire.
  • Fichier complet épinglé : le fichier a été sérialisé explicitement par l’utilisateur via Explorateur de fichiers et sa disponibilité hors connexion est garantie.

L’image suivante montre comment les états fichier d’espace réservé, complet, complet épinglé sont affichés dans Explorateur de fichiers.

Inscription racine de synchronisation standardisée

• 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 d’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 de fichiers cloud fournit des icônes d’état de sérialisation automatiques standardisées affichées dans Explorateur de fichiers et sur le bureau Windows.
  • Outre les icônes d’état Windows standard utilisées pour l’état d’sérialisation, vous pouvez fournir des icônes d’état personnalisées pour des propriétés supplémentaires spécifiques au service.
  • Remplace les extensions Shell d’icône de recouvrement héritée.
• Indication de progression :
  • Ouvrir un fichier d’espace réservé qui prend plus de quelques secondes pour se sérialiser affiche la progression de la sérialisation. 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 Explorateur de fichiers.
    • Si le fichier n’est pas ouvert lors de 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é de sérialisation involontaire.
• Miniatures et métadonnées :
  • Les fichiers d’espace réservé peuvent avoir des miniatures fournies par le service riches et des métadonnées de fichier étendues pour fournir à l’utilisateur une expérience Explorateur de fichiers fluide.
• Volet de navigation Explorateur de fichiers :
  • L’inscription d’une racine de synchronisation avec l’API de fichiers cloud entraîne l’affichage de la racine de synchronisation (avec une icône et un nom personnalisé) dans le volet de navigation d’Explorateur de fichiers.
• Menus contextuels d'Explorateur de fichiers :
  • L’inscription d’une racine de synchronisation avec l’API de fichiers cloud fournit automatiquement plusieurs verbes (entrées de menu) dans le menu contextuel d’Explorateur de fichiers, qui permettent à l’utilisateur de contrôler l’état de sérialisation de son fichier.
  • Des verbes supplémentaires peuvent être ajoutés à cette section du menu contextuel à l’aide d’API compatibles avec Pont du bureau.
• Contrôle utilisateur de la sérialisation des fichiers :
  • Les utilisateurs contrôlent toujours la sérialisation des fichiers, même s’ils ne sont pas sérialisés explicitement par l’utilisateur. Un toast interactif s’affiche pour la sérialisation en arrière-plan pour alerter l’utilisateur et fournir des options. L’image suivante illustre une notification toast pour un fichier de sérialisation.
  • Si un utilisateur bloque une application à partir de fichiers se sérialisant par le biais d’un toast interactif, il peut débloquer l’application dans la page Téléchargements automatiques de fichiers dans Paramètres.
• Raccordement des opérations de moteur de copie (pris en charge dans Windows 10 Insider Build de préversion 19624 et versions ultérieures) :
  • Les fournisseurs de stockage cloud peuvent inscrire un hook de copie shell pour surveiller les opérations de fichier à l’intérieur 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 IStockageProviderCopyHook.
• 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.

Pont du bureau

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

Exemple Miroir Cloud

L’exemple Miroir Cloud montre comment créer une solution qui utilise l’API de fichiers cloud. Il n’est pas destiné à être utilisé comme code de production. Il ne dispose pas d’une gestion des erreurs robuste et est écrit pour être compris le plus facilement possible. Il est appelé Miroir Cloud, car il reflète simplement 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 d’Explorateur de fichiers appelé TestStockageProviderDisplayName, et ce nœud est mappé au dossier client spécifié.

En ce qui concerne la synchronisation, voici 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 la sérialisation. 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 ce changement, et le client de synchronisation local doit gérer les fusions en fonction de ses propres spécifications. Cette opération n’est pas implémentée 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 serveur et l’autre, comme client.
2. Ajoutez certains fichiers au dossier du serveur. Vérifiez que le dossier client est vide.
3. Ouvrez l’exemple Miroir Cloud 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. Lorsque c’est fait, une fenêtre de console s’affiche avec des informations de diagnostic.
4. Ouvrez Explorateur de fichiers et vérifiez que vous voyez le nœud TestStockageProviderDisplayName 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’une d’entre elles dans votre dossier racine de synchronisation et vérifiez qu’elle se sérialise. Ensuite, ouvrez l’application Photos. L’application charge les fichiers adjacents en arrière-plan pour minimiser les chances que l’utilisateur subisse des retards lors de la recherche dans les autres images. Vous pouvez observer la désérialisation en arrière-plan par le biais de toasts ou dans Explorateur de fichiers.
5. Cliquez avec le bouton droit sur un fichier dans Explorateur de fichiers pour afficher un menu contextuel, puis vérifiez que vous voyez l’élément de menu TestCommand. Cliquer sur cet élément de menu affiche une zone 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’inscription de racine de synchronisation afin que le fournisseur soit désinstallé. Si l’exemple se bloque, il est possible que la racine de synchronisation reste inscrite. À cause de cela, Explorateur de fichiers se relancera à chaque fois que vous cliquez sur quoi que ce soit, et vous serez invité à entrer les faux emplacements du client et du serveur. Si cela se produit, désinstallez l’exemple d’application CloudMirrorPackage à partir de votre ordinateur.

Exemple d’architecture

L’exemple est délibérément simple. Il utilise des classes statiques pour ne pas avoir à passer de 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.
  • Placeholders : génère les fichiers d’espace réservé 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 lentement les fichiers du dossier serveur vers le dossier client en blocs pour simuler le téléchargement à partir d’un serveur cloud réel. Fournit une indication de progression afin que les toasts et l’interface utilisateur Explorateur de fichiers montrent à l’utilisateur quelque chose d’informatif.

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 dans l’API de fichiers cloud se trouve un pilote de minifiltre 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, mais c’est à cldflt.sys de travailler avec l’interpréteur de commandes Shell 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 il dépend de certaines fonctionnalités propres à NTFS.

Il existe de nombreux pilotes de minifiltre de système de fichiers dans un système et ils 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 du système de fichiers antivirus.

Les pilotes de minifiltre 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 de sérialisation

Windows prend en charge une variété de modificateurs de stratégies de sérialisation principales et stratégies de sérialisation secondaires. Les stratégies de sérialisation principales sont dans cet ordre :

Toujours complète > Complète > Progressive > Partielle

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

La stratégie de sérialisation 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 le lecteur cloud Fabrikam à l’aide de la visionneuse de fichiers PDF Contoso, qui ne spécifie pas de stratégie de sérialisation préférée. La stratégie de sérialisation de l’application est donc une sérialisation progressive par défaut. Toutefois, étant donné que le lecteur cloud Fabrikam est un moteur de synchronisation de sérialisation complète, la stratégie finale de sérialisation sur le fichier devient une sérialisation complète, ce qui entraînera la sérialisation complète 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 la sérialisation progressive, mais la préférence de l’application est une sérialisation complète.

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

Compatibilité avec les applications qui utilisent des points d’analyse

L’API de fichiers cloud implémente le système d’espace réservé à l’aide de points d’analyse. Une erreur courante concernant les points d’analyse est de penser qu’ils sont l’équivalent de liens symboliques. Cette idée reçue se reflète parfois dans les implémentations d’applications, et par conséquent, de nombreuses applications existantes rencontrent des erreurs face à un point d’analyse.

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