Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 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 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 el punto 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 compatibles
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 convierten 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 aplicaciones con archivos de marcador de posición generalmente no es un problema. Tanto si usas APIs del sistema de archivos, el símbolo del sistema, una aplicación de escritorio o una aplicación UWP para acceder a un archivo de marcador de posición, el archivo se cargará sin cambios de código adicionales y esa aplicación puede usar el archivo normalmente.
- Los archivos pueden existir en tres estados:
- Archivo marcador de posición: una representación vacía del archivo, disponible solo si el servicio de sincronización está operativo.
- 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 del Explorador de Windows y se asegura su disponibilidad sin conexión.
En la imagen siguiente se muestra cómo aparecen los estados de archivo marcador de posición, completo y completo anclado en el Explorador de archivos.
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 del 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 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.
- 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 en función del contexto:
- En una ventana de diálogo del motor de copia.
- El progreso en línea se muestra junto al archivo en el Explorador de archivos.
- Si el archivo no se abre según la instrucción específica del usuario, se muestra una notificación emergente para informar al usuario y proporcionar una manera de controlar la actividad de hidratación no deseada.
- 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:
- 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 sin problemas del 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 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 emergente para un archivo en proceso de actualización.
- Si un usuario bloquea que una aplicación procese archivos a través de una notificación interactiva del sistema, puede desbloquear la aplicación en la página Descargas automáticas de archivos en Configuración.
- 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 emergente para un archivo en proceso de actualización.
- Operaciones de intercepción del motor de copia (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 gancho de copia estableciendo el valor del registro CopyHook 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 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 recursos compartidos 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 del Registro de ShareHandler en la clave del Registro raíz de sincronización al CLSID de su objeto de servidor local COM. Este objeto de servidor local implementa la interfaz IExplorerCommand .
Puente 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 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á pensado para usarse como código de producción. Carece de un control sólido de errores y se escribe para ser lo más fácil de entender 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 denominado 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 debe implementar un proveedor de sincronización de archivos en la nube totalmente desarrollado:
- Cuando el archivo raíz de sincronización es solo un marcador de posición, el servicio es responsable de copiar los contenidos del archivo para que se efectúe 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 contiene todos los datos y los contenidos del archivo en la ruta raíz de sincronización (el cliente local) cambian, el cliente de sincronización local debe notificar al servicio en la nube y gestionar 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
- Cree dos carpetas en el disco duro local. Uno de ellos actuará como el servidor y el otro como el cliente.
- Agregue algunos archivos a la carpeta del servidor. Asegúrese de que la carpeta del cliente está vacía.
- 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 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.
- 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 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 mediante notificaciones emergentes o en el Explorador de archivos.
- Haga clic con el botón derecho en un archivo en el 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.
- 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 la muestra 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
La muestra es deliberadamente sencilla. 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: genera los archivos marcadores 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 ofrezcan al usuario información útil.
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 está 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 de minifiltro del sistema de archivos se administran y se admiten mediante un componente especial en modo núcleo conocido como el 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 principal y modificadores de 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 principal 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. 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 total, la directiva de hidratación final en el archivo se convierte en hidratación total, lo que resultará en que el archivo se hidrate completamente cuando se accede por primera vez. 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 política de hidratación de archivos no se puede cambiar después de que el archivo haya sido abierto.
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 reparación. Una idea errónea común sobre los puntos de reanálisis es que son lo mismo que los vínculos simbólicos. Esta idea errónea se refleja ocasionalmente en las implementaciones de aplicaciones y, como resultado, muchas aplicaciones existentes provocan 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.
Búsqueda de archivos en la nube
La búsqueda de archivos en la nube se admite en Windows 11, versión 24H2 y posteriores, en equipos Copilot+ o PC en la nube habilitados para IA. Las siguientes características están disponibles para que los proveedores de almacenamiento en la nube se integren con la experiencia de Windows Search:
- Los proveedores de almacenamiento en la nube pueden registrar un controlador de búsqueda de archivos para su raíz de sincronización, lo que les permite contribuir a los resultados de búsqueda del Explorador de archivos de Windows y de Windows Search.
- Los proveedores de almacenamiento en la nube registran un controlador de búsqueda estableciendo el valor del Registro SearchHandlerFactory en su clave del registro raíz de sincronización en el CLSID de su objeto de servidor local COM. Este objeto de servidor local implementa la interfaz IStorageProviderSearchHandlerFactory .
- IStorageProviderSearchHandlerFactory crea una implementación de IStorageProviderSearchHandler. Esta implementación de IStorageProviderSearchHandler llama al servicio de búsqueda del proveedor de nube para buscar archivos que podrían no estar disponibles localmente en el dispositivo.
- La experiencia de Windows Search llama al método Find durante una búsqueda, combinando sus resultados con los del indexador de búsqueda local.
Contenido relacionado
Integración del proveedor de archivos en la nube con Windows Search