Crear un motor de sincronización en la nube que admita archivos de marcador de posición

Un motor de sincronización es un servicio que sincroniza archivos, normalmente entre un host remoto y un cliente local. Los motores de sincronización en Windows suelen presentar esos archivos al usuario a través del sistema de archivos de Windows y el Explorador de archivos. Antes de Windows 10, versión 1709, la compatibilidad con el motor de sincronización en Windows se limitaba a superficies ad hoc independientes del escenario, como el panel de navegación del Explorador de archivos, la bandeja del sistema de Windows y (para aplicaciones más técnicas) controladores de filtro del sistema de archivos.

La versión 1709 de Windows 10 (también llamada Fall Creators Update) introdujo la API de archivos en la nube. Esta API es una nueva plataforma que formaliza la compatibilidad con los motores de sincronización. La API de archivos en la nube proporciona compatibilidad con los motores de sincronización de una manera que ofrece muchas ventajas nuevas a los desarrolladores y usuarios finales.

La API de archivos en la nube contiene las siguientes API nativas de Win32 y las API de Windows Runtime (WinRT):

• API de filtro en la nube: esta API nativa de Win32 proporciona funcionalidad en el límite entre el modo de usuario y el sistema de archivos. Esta API controla la creación y administración de archivos y directorios de marcador de posición.
• Espacio de nombres Windows.Storage.Provider: esta API de WinRT permite a las aplicaciones configurar el proveedor de almacenamiento en la nube y registrar la raíz de sincronización con el sistema operativo.

Nota:

La API de archivos en la nube no admite actualmente la implementación de motores de sincronización en la nube en aplicaciones para UWP. Los motores de sincronización en la nube deben implementarse en aplicaciones de escritorio.

Características admitidas

La API de archivos en la nube proporciona las siguientes características para crear motores de sincronización en la nube.

Archivos de marcador de posición

• Los motores de sincronización pueden crear archivos de marcadores de posición que solo consumen 1 KB de almacenamiento para la cabecera del sistema de archivos, y que se hidratan automáticamente en archivos completos en condiciones normales de uso. Los archivos de marcadores de posición se presentan como archivos típicos a las aplicaciones y a los usuarios finales en el Shell de Windows.
• Los archivos de marcadores de posición están integrados verticalmente desde el núcleo de Windows hasta el shell de Windows, y la compatibilidad de las aplicaciones con los archivos de marcadores de posición no suele ser un problema. Tanto si usa las API del sistema de archivos, el símbolo del sistema o una aplicación de escritorio o UWP para acceder a un archivo de marcador de posición, el archivo se hidratará sin cambios adicionales en el código y esa aplicación podrá utilizar el archivo con normalidad.
• Los archivos pueden existir en tres estados:
  • Archivo de marcador de posición: una representación vacía del archivo y solo está disponible si el servicio de sincronización está disponible.
  • Archivo completo: el archivo se ha hidratado implícitamente y podría ser deshidratado por el sistema si se necesita espacio.
  • Archivo completo anclado: El archivo ha sido hidratado explícitamente por el usuario a través del Explorador de archivos y se garantiza que estará disponible sin conexión.

La siguiente imagen muestra cómo se muestran en el Explorador de archivos los estados de marcador de posición, archivo completo y archivo completo anclado.

Registro raíz de sincronización normalizado

• El registro de una raíz de sincronización es sencillo y estandarizado. Esto incluye la creación de un nodo con marca en el panel de navegación del Explorador de archivos, como se muestra en la siguiente captura de pantalla. Las raíces se pueden crear como entradas individuales de nivel superior o como elementos secundarios de una agrupación primaria.

  

Integración de Shell

• Iconos de estado:
  • La API de archivos en la nube proporciona iconos de estado de hidratación automática estandarizados que se muestran en el Explorador de archivos y en el escritorio de Windows.
  • Además de los iconos de estado estándar de Windows que se usan para el estado de hidratación, puede proporcionar iconos de estado personalizados para propiedades específicas del servicio adicionales.
  • Sustituye a las extensiones Shell de superposición de iconos heredadas.
• Indicación de progreso:
  • Al abrir un archivo de marcador de posición que tarda más de unos segundos en hidratarse, se mostrará el progreso de la hidratación. El progreso se muestra en algunas ubicaciones en función del contexto:
    • En una ventana de diálogo del motor de copia.
    • El progreso insertado se muestra junto al archivo en el Explorador de archivos.
    • Si el archivo no se abre siguiendo las instrucciones específicas del usuario, se mostrará un mensaje emergente para informar al usuario y proporcionarle una forma de controlar la actividad de hidratación no deseada.
• Miniaturas y metadatos:
  • Los archivos de marcadores de posición pueden tener miniaturas enriquecidas proporcionadas por el servicio y metadatos de archivo ampliados para ofrecer al usuario una experiencia perfecta con el Explorador de archivos.
• Panel de navegación del Explorador de archivos:
  • El registro de una raíz de sincronización con la API de archivos en la nube hace que la raíz de sincronización (con un icono y un nombre personalizado) aparezca en el panel de navegación del Explorador de archivos.
• Menús contextuales del Explorador de archivos:
  • El registro de una raíz de sincronización con la API de archivos en la nube proporciona automáticamente varios verbos (entradas de menú) en el menú contextual del Explorador de archivos que permiten al usuario controlar el estado de hidratación de su archivo.
  • Se pueden agregar verbos adicionales a esta sección del menú contextual mediante las API compatibles con puente de dispositivo de escritorio.
• Control de usuario de la hidratación de archivos:
  • Los usuarios siempre están en control de la hidratación de archivos, incluso cuando el usuario no hidrata explícitamente los archivos. Se muestra un brindis interactivo por la hidratación de fondo para alertar al usuario y ofrecerle opciones. En la siguiente imagen se muestra una notificación del sistema para un archivo de hidratación.
  • Si un usuario bloquea una aplicación de hidratar archivos a través de un mensaje emergente interactivo, puede desbloquear la aplicación en la página Descargas automáticas de archivos en Configuración.
• Operaciones del motor de copia de enlace (compatibles con Windows 10 Insider Preview Build 19624 y versiones posteriores):
  • Los proveedores de almacenamiento en la nube pueden registrar un enlace de copia de shell para supervisar las operaciones de archivos dentro de su raíz de sincronización.
  • El proveedor registra su enlace de copia estableciendo el valor de registro CopyHook en su clave de registro raíz de sincronización con el CLSID de su objeto de servidor local COM. Este objeto de servidor local implementa la interfaz IStorageProviderCopyHook.
• Uso compartido de archivos (compatible con Windows 11 versión 21H2 y versiones posteriores):
  • Los proveedores de almacenamiento en la nube pueden registrar un controlador de uso compartido que se invocará cuando el usuario seleccione el comando "Compartir" en un archivo en la nube en su raíz de sincronización.
  • El proveedor registra su controlador de recursos compartidos estableciendo el valor de registro ShareHandler bajo su clave de registro raíz de sincronización en el CLSID de su objeto de servidor local COM. Este objeto de servidor local implementa la interfaz IExplorerCommand.

Puente de dispositivo de escritorio

• Los motores de sincronización que usan las API de archivos en la nube están diseñados para usar el puente de dispositivo escritorio como requisito de implementación.

Ejemplo de Cloud Mirror

En el ejemplo de Cloud Mirror se muestra cómo crear una solución que use la API de archivos en la nube. No está pensado para usarse como código de producción. Carece de un tratamiento de errores robusto y está escrito para que se entienda lo más fácilmente posible. Se denomina Cloud Mirror porque simplemente refleja una carpeta local en el disco local. Especifique una carpeta de servidor diseñada para representar el servidor de archivos en la nube y una carpeta de cliente diseñada para especificar la ruta de acceso raíz de sincronización. Aparece un nodo de nivel superior en el panel de navegación del Explorador de archivos llamado TestStorageProviderDisplayName, y este nodo se asigna a la carpeta cliente especificada.

Cuando se trata de sincronizar, estas son las cosas que un proveedor de sincronización de archivos en la nube completamente desarrollado debe implementar:

• Cuando el archivo raíz de sincronización es solo un marcador de posición, el servicio es responsable de copiar el contenido del archivo para la hidratación. Esto se implementa en la muestra.
• Cuando el archivo raíz de sincronización es un archivo completo y el contenido del archivo en el servicio en la nube cambia, el servicio se encarga de notificar el cambio al cliente de sincronización local, que debe administrar las fusiones según sus propias especificaciones. Esto no se implementa en el ejemplo.
• Cuando el archivo raíz de sincronización es un archivo completo y el contenido del archivo en la ruta de acceso raíz de sincronización (el cliente local), el cliente de sincronización local debe notificar al servicio en la nube y controlar las combinaciones según sus propias especificaciones. La notificación de cambio de archivo local se implementa en la muestra, pero no hace nada.

Uso del ejemplo

1. Cree dos carpetas en el disco duro local. Uno de ellos actuará como el servidor y el otro como el cliente.
2. Agregue algunos archivos a la carpeta del servidor. Asegúrese de que la carpeta del cliente está vacía.
3. Abra el ejemplo de Cloud Mirror en Visual Studio. Establezca el proyecto CloudMirrorPackage como proyecto de inicio y luego compile y ejecute el ejemplo. Cuando lo solicite el ejemplo, escriba las dos rutas de acceso a las carpetas de servidor y cliente. Después de esto, verá una ventana de consola con información de diagnóstico.
4. Abra el Explorador de archivos y confirme que ve el nodo TestStorageProviderDisplayName y los marcadores de posición de todos los archivos que copió en la carpeta del servidor. Para simular una aplicación que intenta abrir archivos sin usar el selector, copie varias imágenes en la carpeta del servidor. Haga doble clic en uno de ellos en la carpeta raíz de sincronización y confirme que se hidrata. A continuación, abra la aplicación Fotos. La aplicación cargará previamente los archivos adyacentes en segundo plano para que el usuario no experimente retrasos al mirar las demás imágenes. Puede observar que la deshidratación en segundo plano se produce a través de mensajes emergentes o en el Explorador de archivos.
5. Haga clic con el botón derecho en un archivo del Explorador de archivos para abrir un menú contextual y confirme que ve el elemento de menú TestCommand. Al hacer clic en este elemento del menú, se mostrará un cuadro de mensaje.
6. Para detener el ejemplo, establezca el foco en la salida de la consola y presione Ctrl-C. Esto limpiará el registro raíz de sincronización para que se desinstale el proveedor. Si el ejemplo se bloquea, es posible que la raíz de sincronización permanezca registrada. Esto hará que el Explorador de archivos vuelva a iniciarse cada vez que haga clic en cualquier cosa y se le solicitará la ubicación falsa del cliente y del servidor. Si esto ocurre, desinstale la aplicación de ejemplo CloudMirrorPackage del equipo.

Arquitectura de muestra

El ejemplo es deliberadamente sencillo. Usa clases estáticas para que no sea necesario pasar punteros de instancia. Estas son las clases principales del ejemplo:

• FakeCloudProvider: esta clase de nivel superior controla las siguientes clases de trabajo:
  • CloudProviderRegistrar: registra la información raíz de sincronización con el Shell de Windows.
  • Marcadores de posición: genera los archivos de marcador de posición en la ruta de acceso raíz de sincronización.
  • ShellServices: construye los proveedores de Shell de Windows para el menú contextual, las miniaturas y otros servicios.
  • CloudProviderSyncRootWatcher: crea una instancia de DirectoryWatcher para supervisar los cambios en la ruta de acceso raíz de sincronización y actuar sobre los cambios.
  • FileCopierWithProgress: copia archivos de la carpeta del servidor en la carpeta cliente lentamente en fragmentos para simular su descarga desde un servidor en la nube real. Proporciona una indicación de progreso para que las notificaciones del sistema y la interfaz de usuario del Explorador de archivos muestren al usuario algo informativo.

Además de las clases anteriores, el ejemplo también proporciona varias clases auxiliares para solicitar al usuario carpetas y algunas utilidades. TestExplorerCommandHandler, CustomStateProvider, ThumbnailProvider y UriSource son ejemplos de proveedores de servicios de Shell.

Arquitectura de la API de archivos en la nube

En el núcleo de la pila de almacenamiento de la API de archivos en la nube se encuentra un controlador de minifiltro del sistema de archivos llamado cldflt.sys. Este controlador actúa como proxy entre las aplicaciones del usuario y el motor de sincronización. Su motor de sincronización sabe cómo descargar y cargar los datos bajo demanda, mientras que es responsabilidad de cldflt.sys trabajar con el Shell para presentar los archivos como si los datos de la nube estuvieran disponibles localmente.

Cldflt.sys actualmente solo admite volúmenes NTFS porque depende de algunas características exclusivas de NTFS.

Hay muchos controladores de minifiltro de sistema de archivos en un sistema y pueden estar activos en un volumen determinado al mismo tiempo. Los controladores que son de mayor interés para la API de archivos en la nube son los filtros del sistema de archivos antivirus.

Los controladores de minifiltros del sistema de archivos son administrados y soportados por un componente especial del modo kernel llamado gestor de filtros. Entre otras muchas funciones, el administrador de filtros facilita la comunicación no filtrada entre los filtros y los componentes del modo de usuario a través de una construcción conocida como puerto de mensajes de filtro.

Directivas de hidratación

Windows admite una variedad de modificadores de directivas de hidratación principal y directiva de hidratación secundaria. Las directivas de hidratación principal tienen este orden:

Siempre completa> Completa > Progresiva > Parcial

Tanto las aplicaciones como los motores de sincronización pueden definir su directiva de hidratación primaria preferida. Si no se especifica, la directiva de hidratación predeterminada es progresiva para las aplicaciones y los motores de sincronización.

La directiva de hidratación de un archivo en la nube se determina en tiempo de apertura del archivo mediante esta fórmula:

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

Por ejemplo, supongamos que el usuario está intentando abrir un archivo PDF almacenado en Fabrikam Cloud Drive mediante contoso PDF Viewer, que no especifica una directiva de hidratación preferida. La directiva de hidratación de la aplicación es, por tanto, la hidratación progresiva, en este caso de manera predeterminada. Sin embargo, debido a que Fabrikam Cloud Drive es un motor de sincronización de hidratación completa, la directiva de hidratación final del archivo se convierte en hidratación completa, lo que hará que el archivo se hidrate completamente en el primer acceso. El mismo resultado ocurre en los casos en los que el motor de sincronización admite la hidratación progresiva, pero la preferencia de la aplicación es la hidratación completa.

Tenga en cuenta que la directiva de hidratación de archivos no puede modificarse una vez abierto el archivo.

Compatibilidad con aplicaciones que usan puntos de reanálisis

La API de archivos en la nube implementa el sistema de marcador de posición mediante puntos de reanálisis. Una idea errónea común sobre los puntos de reanálisis es que son iguales que los vínculos simbólicos. Esta idea errónea se refleja ocasionalmente en las implementaciones de aplicaciones y, como resultado, muchas aplicaciones existentes alcanzan errores al encontrar cualquier punto de reanálisis.

Para mitigar este problema de compatibilidad, la API de archivos en la nube siempre oculta sus puntos de reanálisis de todas las aplicaciones, excepto los motores de sincronización y los procesos cuya imagen principal reside en %systemroot%. Las aplicaciones que entienden los puntos de reanálisis correctamente pueden forzar a la plataforma a exponer puntos de reanálisis de API de archivos en la nube mediante RtlSetProcessPlaceholderCompatibilityMode o RtlSetThreadProcessPlaceholderCompatibilityMode.