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 a menudo presentan esos archivos al usuario a través del sistema de archivos Windows y 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 de Explorador de archivos, la bandeja del sistema de Windows y (para aplicaciones más técnicas) los controladores de filtro del sistema de archivos.

Windows 10 versión 1709 (también denominada 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 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 directorios y archivos de marcador de posición.
• Windows.Storage. Espacio de nombres del proveedor: 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 marcador de posición que consumen solo 1 KB de almacenamiento para el encabezado del sistema de archivos y que se hidratan automáticamente en archivos completos en condiciones de uso normales. Los archivos de marcador de posición se presentan como archivos típicos para las aplicaciones y para los usuarios finales en el shell de Windows.
• Los archivos de marcador de posición se integran verticalmente desde el kernel de Windows hasta el shell de Windows y la compatibilidad de la aplicación con los archivos de marcador de posición suele ser un problema. Tanto si usas api del sistema de archivos, el símbolo del sistema, un escritorio o una aplicación para UWP para acceder a un archivo de marcador de posición, el archivo se hidratará sin cambios de código adicionales y esa aplicación puede usar el archivo normalmente.
• Los archivos pueden existir en tres estados:
  • Archivo de marcador de posición: 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 usuario ha hidratado explícitamente el archivo a través de Explorador de archivos y se garantiza que está disponible sin conexión.

En la imagen siguiente se muestra cómo se muestran en Explorador de archivos los estados de archivo completo, completo y anclado.

Registro raíz de sincronización estandarizado

• 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 de Explorador de archivos, como se muestra en la captura de pantalla siguiente. 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 Explorador de archivos y en el escritorio de Windows.
  • Además de los iconos de estado de Windows estándar que se usan para el estado de hidratación, puede proporcionar iconos de estado personalizados para propiedades específicas del servicio adicionales.
  • Reemplaza las extensiones de shell de superposición de iconos heredados.
• 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 según el contexto:
    • En una ventana de diálogo del motor de copia.
    • El progreso insertado se muestra junto al archivo en Explorador de archivos.
    • Si el archivo no se abre en la instrucción específica del usuario, se muestra una notificación del sistema para informar al usuario y proporcionar una manera de controlar la actividad de hidratación no deseada.
• Miniaturas y metadatos:
  • Los archivos de marcador de posición pueden tener miniaturas enriquecidas proporcionadas por el servicio y metadatos de archivo extendidos para proporcionar al usuario una experiencia Explorador de archivos sin problemas.
• Explorador de archivos panel de navegación:
  • 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 de Explorador de archivos.
• Explorador de archivos menús contextuales:
  • 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 de Explorador de archivos que permite 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 una notificación del sistema interactiva para la hidratación en segundo plano para alertar al usuario y proporcionar opciones. En la imagen siguiente se muestra una notificación del sistema para un archivo de hidratación.
  • Si un usuario impide que una aplicación hidrata los archivos a través de una notificación del sistema interactiva, 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 la compilación 19624 y posteriores de Windows 10 Insider Preview):
  • 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 del Registro CopyHook en su clave del Registro raíz de sincronización en un CLSID de su objeto de servidor local COM. Este objeto de servidor local implementa la interfaz IStorageProviderCopyHook .

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 la Puente de dispositivo de escritorio como requisito de implementación.

Ejemplo de reflejo en la nube

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á diseñado para usarse como código de producción. Carece de un control de errores sólido y se escribe para que se entienda lo más fácilmente posible. Se llama 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 que esté pensada para especificar la ruta de acceso raíz de sincronización. Aparece un nodo de nivel superior en el panel de navegación de Explorador de archivos llamado TestStorageProviderDisplayName y este nodo se asigna a la carpeta de cliente especificada.

En lo que respecta a la sincronización, estos son los aspectos que un proveedor de sincronización de archivos en la nube totalmente 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 el ejemplo.
• 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 es responsable de notificar al cliente de sincronización local del cambio y el cliente de sincronización local debe controlar las combinaciones 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 el ejemplo, 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 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, a continuación, compile y ejecute el ejemplo. Cuando se le solicite en 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 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 hidrata. A continuación, abra la aplicación Fotos. La aplicación cargará previamente los archivos adyacentes en segundo plano para que sea más probable que el usuario no experimente retrasos al examinar las otras imágenes. Puede observar que la deshidratación en segundo plano se produce a través de notificaciones del sistema o en Explorador de archivos.
5. Haga clic con el botón derecho en un archivo en Explorador de archivos para abrir un menú contextual y confirme que ve el elemento de menú TestCommand. Al hacer clic en este elemento de 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 Explorador de archivos vuelvan a iniciarse cada vez que haga clic en cualquier cosa y se le pedirán las ubicaciones de cliente y servidor falsas. 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 de 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 API de archivos en la nube

En el núcleo de la pila de almacenamiento de la API de archivos en la nube, se trata de un controlador de minifiltro del sistema de archivos denominado cldflt.sys. Este controlador actúa como proxy entre las aplicaciones del usuario y el motor de sincronización. El motor de sincronización sabe cómo descargar y cargar los datos a petición mientras es responsabilidad de cldflt.sys trabajar con el Shell para presentar archivos como si los datos en 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 del 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 minifiltros del sistema de archivos son administrados y compatibles con un componente especial en modo kernel denominado administrador de filtros. Entre muchas otras tareas, el administrador de filtros facilita la comunicación sin filtrar entre los filtros y los componentes del modo de usuario a través de una construcción conocida como puerto de mensaje de filtro.

Directivas de hidratación

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

Siempre completo > total > parcial >

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

Esta fórmula determina la directiva de hidratación de un archivo en la nube en el momento de apertura del archivo:

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. Por lo tanto, la directiva de hidratación de la aplicación es la hidratación progresiva, en este caso de forma predeterminada. Sin embargo, dado que Fabrikam Cloud Drive es un motor de sincronización de hidratación completa, la directiva de hidratación final en el archivo se convierte en hidratación completa, lo que hará que el archivo esté totalmente hidratado en el primer acceso. El mismo resultado se produce 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 se puede cambiar después de abrir 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 comprenden correctamente los puntos de reanálisis pueden forzar a la plataforma a exponer puntos de análisis de API de archivos en la nube mediante RtlSetProcessPlaceholderCompatibilityMode o RtlSetThreadProcessPlaceholderCompatibilityMode.