Создание подсистемы облачной синхронизации, поддерживающей файлы заполнителей

Подсистема синхронизации — это служба, которая синхронизирует файлы, обычно между удаленным узлом и локальным клиентом. Подсистемы синхронизации в Windows часто представляют эти файлы пользователю через файловую систему Windows и проводник. До Windows 10 версии 1709 поддержка подсистемы синхронизации в Windows была ограничена сценариями нерегламентированных поверхностей, таких как панель навигации проводник, область навигации Windows и (для дополнительных технических приложений) драйверов фильтров файловой системы.

Windows 10 версии 1709 (также называется Fall Creators Update) представила API облачных файлов. Этот API — это новая платформа, которая формализирует поддержку обработчиков синхронизации. API облачных файлов обеспечивает поддержку обработчиков синхронизации таким образом, что предлагает множество новых преимуществ для разработчиков и конечных пользователей.

API облачных файлов содержит следующие собственные API Win32 и API-интерфейсы среда выполнения Windows (WinRT):

• API облачного фильтра. Этот собственный API Win32 предоставляет функциональные возможности между пользовательским режимом и файловой системой. Этот API обрабатывает создание и управление заполнителями файлов и каталогов.
• Windows. служба хранилища. Пространство имен поставщика. Этот API WinRT позволяет приложениям настроить поставщика облачного хранилища и зарегистрировать корневой каталог синхронизации в операционной системе.

Поддерживаемые функции

API облачных файлов предоставляет следующие функции для создания обработчиков облачной синхронизации.

Заполнители файлов

• Подсистемы синхронизации могут создавать файлы заполнителей, которые используют только 1 КБ хранилища для заголовка файловой системы и автоматически гидратированные в полные файлы в условиях нормального использования. Файлы заполнителей представляются как типичные файлы для приложений и конечных пользователей в оболочке Windows.
• Файлы заполнителей вертикально интегрируются из ядра Windows до оболочки Windows, а совместимость приложений с заполнителями обычно не является проблемой. Независимо от того, используете ли вы API файловой системы, командную строку или классическое приложение или приложение UWP для доступа к заполнителю, файл будет гидратироваться без дополнительных изменений кода, и это приложение может использовать файл обычно.
• Файлы могут существовать в трех состояниях:
  • Заполнитель файла: пустое представление файла и доступно только в том случае, если служба синхронизации доступна.
  • Полный файл: файл был гидратирован неявно и может быть обезвожен системой, если требуется пространство.
  • Закрепленный полный файл: файл был явно гидратирован пользователем через проводник и гарантированно доступен в автономном режиме.

На следующем рисунке показано, как заполнитель, полный и закрепленный полный файл отображаются в проводник.

Стандартизованная регистрация корневой папки синхронизации

• Регистрация корневого каталога синхронизации является простой и стандартизированной. Это включает создание фирменного узла в области навигации проводник, как показано на следующем снимке экрана. Корни можно создавать как отдельные записи верхнего уровня, так и как дочерние элементы родительской группировки.

  

Интеграция оболочки

• Значки состояния:
  • API облачных файлов предоставляет стандартные, автоматические значки состояния гидратации, отображаемые в проводник и на рабочем столе Windows.
  • Помимо стандартных значков состояния Windows, используемых для состояния гидратации, можно предоставить пользовательские значки состояния для дополнительных свойств, относящихся к службе.
  • Заменяет устаревшие расширения оболочки значка.
• Индикатор хода выполнения:
  • Открытие заполнителя, который занимает более нескольких секунд, чтобы гидратировать, будет отображать ход гидратации. Ход выполнения отображается в нескольких расположениях в зависимости от контекста:
    • В диалоговом окне обработчика копирования.
    • Встроенный ход выполнения отображается рядом с файлом в проводник.
    • Если файл не открыт по определенной инструкции пользователя, отображается всплывающее уведомление для информирования пользователя и предоставления способа управления непреднамеренное действие гидратации.
• Эскизы и метаданные:
  • Файлы заполнителей могут иметь расширенные эскизы и расширенные метаданные файлов, чтобы предоставить пользователю простой проводник интерфейс.
• панель навигации проводник:
  • Регистрация корневого каталога синхронизации с помощью API облачных файлов приводит к тому, что корень синхронизации (с значком и пользовательским именем) появится в области навигации проводник.
• проводник контекстных меню:
  • Регистрация корневого каталога синхронизации в API облачных файлов автоматически предоставляет несколько команд (записей меню) в контекстном меню проводник, которое позволяет пользователю управлять состоянием гидратации файла.
  • Дополнительные команды можно добавить в этот раздел контекстного меню с помощью API, совместимых с мост для классических приложений.
• Пользовательский контроль гидратации файлов:
  • Пользователи всегда контролируют гидратацию файлов, даже если файлы не гидратируются явным образом пользователем. Интерактивное всплывающее уведомление отображается для фоновой гидратации для оповещения пользователя и предоставления параметров. На следующем изображении показано всплывающее уведомление для файла hydrating.
  • Если пользователь блокирует приложение от hydrating файлов с помощью интерактивного всплывающего уведомления, он может разблокировать приложение на странице автоматического скачивания файлов в Параметры.
• Перехват операций обработчика копирования (поддерживается в сборке предварительной версии Windows 10 Insider Preview 19624 и более поздних версиях):
  • Поставщики облачных хранилищ могут зарегистрировать перехватчик копирования оболочки для мониторинга операций с файлами в корневом каталоге синхронизации.
  • Поставщик регистрирует свой перехватчик копирования, задав значение реестра CopyHook в разделе корневого реестра синхронизации с CLSID объекта локального сервера COM. Этот локальный объект сервера реализует интерфейс I служба хранилища ProviderCopyHook.
• Общий доступ к файлам (поддерживается в Windows 11 версии 21H2 и более поздних версиях):
  • Поставщики облачных хранилищ могут зарегистрировать обработчик общих папок, который будет вызываться при выборе пользователем команды "Общий доступ" в облачном файле в корневом каталоге синхронизации.
  • Поставщик регистрирует обработчик общих ресурсов, задав значение реестра ShareHandler в разделе корневого реестра синхронизации с CLSID объекта локального сервера COM. Этот локальный серверный объект реализует интерфейс I Обозреватель Command.

Мост для классических приложений

• Подсистемы синхронизации с помощью API облачных файлов предназначены для использования мост для классических приложений в качестве требования к реализации.

Пример облачного зеркального отображения

В примере Cloud Mirror показано, как создать решение, использующее API облачных файлов. Он не предназначен для использования в качестве рабочего кода. Она не имеет надежной обработки ошибок, и она записывается так же легко, как это возможно. Он называется Cloud Mirror, так как он просто зеркало локальную папку на локальном диске. Укажите папку сервера, которая предназначена для представления облачного файлового сервера и клиентской папки, предназначенной для указания корневого пути синхронизации. Узел верхнего уровня отображается в области навигации проводник с именем Test служба хранилища ProviderDisplayName, а этот узел сопоставляется с указанной клиентской папкой.

Когда речь идет о синхронизации, это то, что должен реализовать полностью разработанный поставщик синхронизации облачных файлов:

• Если корневой файл синхронизации является только заполнителем, служба отвечает за копирование содержимого файла для гидратации. Это реализовано в примере.
• Если корневой файл синхронизации является полным и содержимое файла в облачной службе изменяется, служба отвечает за уведомление клиента локальной синхронизации об изменении, а клиент локальной синхронизации должен обрабатывать слияния в соответствии с собственными спецификациями. Это не реализовано в примере.
• Когда корневой файл синхронизации является полным и содержимое файла в корневом пути синхронизации (локальный клиент), клиент локальной синхронизации должен уведомлять облачную службу и обрабатывать слияния в соответствии с собственными спецификациями. Уведомление об изменении локального файла реализовано в примере, но это не делает ничего.

Использование примера

1. Создайте две папки на локальном жестком диске. Один из них будет выступать в качестве сервера и другого в качестве клиента.
2. Добавьте некоторые файлы в папку сервера. Убедитесь, что папка клиента пуста.
3. Откройте пример Cloud Mirror в Visual Studio. Задайте проект CloudMirrorPackage в качестве запускаемого проекта, а затем создайте и запустите пример. При появлении запроса введите два пути к серверам и клиентским папкам. После этого появится окно консоли с диагностическими сведениями.
4. Откройте проводник и убедитесь, что узел Test служба хранилища ProviderDisplayName и заполнители для всех файлов, скопированных в папку сервера. Чтобы имитировать приложение, которое пытается открыть файлы без использования средства выбора, скопируйте несколько образов в папку сервера. Дважды щелкните один из них в корневой папке синхронизации и убедитесь, что она гидратирует. Затем откройте приложение "Фотографии". Приложение предварительно загружает смежные файлы в фоновом режиме, чтобы сделать его более вероятным, что пользователь не испытывает задержек при просмотре других изображений. Вы можете наблюдать за фоновой дегидратацией через тосты или в проводник.
5. Щелкните правой кнопкой мыши файл в проводник, чтобы открыть контекстное меню, и убедитесь, что отображается пункт меню TestCommand. Если щелкнуть этот пункт меню, появится окно сообщения.
6. Чтобы остановить пример, установите фокус на выходные данные консоли и нажмите клавиши CTRL-C. Это приведет к очистке корневой регистрации синхронизации, чтобы удалить поставщика. Если образец завершится сбоем, возможно, корневой каталог синхронизации останется зарегистрированным. Это приведет к тому, что проводник будет повторно выполняться каждый раз, когда вы щелкаете все, и вы получите запрос на поддельные расположения клиента и сервера. При этом удалите пример приложения CloudMirrorPackage с компьютера.

Пример архитектуры

Пример намеренно прост. Он использует статические классы, чтобы сделать его ненужным для передачи указателей экземпляра. Ниже приведены основные классы в примере:

• FakeCloudProvider: этот класс верхнего уровня управляет следующими рабочими классами:
  • CloudProviderRegistrar: регистрирует корневую информацию синхронизации в Оболочке Windows.
  • Заполнители: создает файлы заполнителей в корневом пути синхронизации.
  • ShellServices: создает поставщики оболочки Windows для контекстного меню, эскизов и других служб.
  • CloudProviderSyncRootWatcher: создает экземпляр DirectoryWatcher для отслеживания изменений корневого пути синхронизации и выполнения изменений.
  • FileCopierWithProgress: копирует файлы из папки сервера в папку клиента медленно в блоках, чтобы имитировать загрузку с реального облачного сервера. Предоставляет индикатор хода выполнения, чтобы выдвигать и проводник пользовательский интерфейс показывает пользователю что-то информативное.

В дополнение к приведенным выше классам пример также предоставляет несколько вспомогательных классов, чтобы запрашивать пользователя для папок и некоторых служебных программ. Тест Обозреватель CommandHandler, CustomStateProvider, ThumbnailProvider и UriSource являются примерами поставщиков служб Shell.

Архитектура API облачных файлов

В основе стека хранилища в API облачных файлов является драйвер минифильтратора файловой системы с именем cldflt.sys. Этот драйвер выступает в качестве прокси-сервера между приложениями пользователя и подсистемой синхронизации. Подсистема синхронизации знает, как скачать и отправить данные по запросу, пока она отвечает за cldflt.sys работать с Оболочкой, чтобы представить файлы, как если бы облачные данные были локально доступны.

Cldflt.sys в настоящее время поддерживает только тома NTFS, так как он зависит от некоторых функций, уникальных для NTFS.

Существует множество драйверов мини-фильтра файловой системы в системе, и они могут быть активными в заданном томе одновременно. Драйверы, которые наиболее заинтересованы в API облачных файлов, являются фильтрами антивирусной файловой системы.

Драйверы мини-фильтра файловой системы управляются и поддерживаются специальным компонентом режима ядра, называемым диспетчером фильтров. Среди многих других обязанностей диспетчер фильтров упрощает нефильтрованное взаимодействие между фильтрами и компонентами пользовательского режима с помощью конструкции, известной как порт сообщения фильтра.

Политики гидратации

Windows поддерживает различные основные политики гидратации и вторичные модификаторы политики гидратации. Основные политики гидратации имеют следующий порядок:

Всегда полный полный > полный прогрессивный > > частичный

Оба приложения и подсистемы синхронизации могут определять предпочтительную политику основного гидратации. Если это не указано, политика гидратации по умолчанию прогрессирует как для приложений, так и для подсистем синхронизации.

Политика гидратации облачного файла определяется во время открытия файла с помощью этой формулы:

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

Например, предположим, что пользователь пытается открыть PDF-файл, хранящийся на облачном диске Fabrikam с помощью средства просмотра PDF Contoso, который не указывает предпочтительную политику гидратации. Таким образом, политика гидратации приложений является прогрессивной гидратацией, в этом случае по умолчанию. Тем не менее, поскольку Fabrikam Cloud Drive является полной подсистемой синхронизации гидратации, последняя политика гидратации файла становится полной гидратацией, что приведет к полному гидратации файла при первом доступе. Тот же результат происходит в случаях, когда подсистема синхронизации поддерживает прогрессивную гидратацию, но предпочтения приложения полностью гидратации.

Обратите внимание, что политика гидратации файлов не может быть изменена после открытия файла.

Совместимость с приложениями, используюющими точки повторного анализа

API облачных файлов реализует систему заполнителей с помощью точек повторного анализа. Распространенное неправильное представление о точках повторного анализа заключается в том, что они совпадают с символьными ссылками. Это неправильное представление иногда отражается в реализации приложений, и в результате многие существующие приложения сталкиваются с ошибками при обнаружении любой точки повторного анализа.

Чтобы устранить эту проблему совместимости, API облачных файлов всегда скрывает свои точки повторного анализа от всех приложений, за исключением подсистем синхронизации и процессов, основной образ которого находится в %systemroot%. Приложения, которые понимают точки повторного анализа, могут правильно заставить платформу предоставлять точки повторного анализа облачных файлов с помощью RtlSetProcessPlaceholderCompatibilityMode или RtlSetThreadProcessPlaceholderCompatibilityMode.