Функция RxPrepareToReparseSymbolicLink (rxprocs.h)
RxPrepareToReparseSymbolicLink настраивает имя объекта файла для упрощения повторного анализа. Эта подпрограмма используется мини-перенаправлениями сети для прохода по символьным ссылкам.
Синтаксис
NTSTATUS RxPrepareToReparseSymbolicLink(
PRX_CONTEXT RxContext,
BOOLEAN SymbolicLinkEmbeddedInOldPath,
PUNICODE_STRING NewPath,
BOOLEAN NewPathIsAbsolute,
PBOOLEAN ReparseRequired
);
Параметры
RxContext
Указатель на структуру RX_CONTEXT.
SymbolicLinkEmbeddedInOldPath
Логическое значение, указывающее, что обнаружена символьная ссылка. Если значение равно TRUE, символьная ссылка была обнаружена при обходе старого пути.
NewPath
Указатель на строку Юникода, содержащую новое имя пути для обхода.
NewPathIsAbsolute
Логическое значение, указывающее, является ли новый путь абсолютным. Если это значение равно FALSE, \Device\Mup следует добавить в начало NewPath. Если это значение равно TRUE, параметр NewPath — это полный путь для повторного выполнения. В этом случае буфер, содержащий NewPath , используется напрямую, а не выделяет новый буфер.
ReparseRequired
Указатель на логическое значение, указывающее, требуется ли повторное определение. Если это значение равно TRUE, требуется повторное определение.
Возвращаемое значение
RxPrepareToReparseSymbolicLink возвращает STATUS_SUCCESS при успешном выполнении или одно из следующих значений ошибки при сбое:
Код возврата | Описание |
---|---|
|
Сбой запроса на удаление. |
|
Недостаточно ресурсов. |
|
В подпрограмму передан недопустимый параметр. Эта ошибка будет возвращена, если член MajorFunctionRxContext не IRP_MJ_CREATE. |
Комментарии
Подпрограмма RxPrepareToReparseSymbolicLink будет использоваться только мини-перенаправлением сети, который поддерживает символьные ссылки и использует точки повторного анализа для реализации символических ссылок. Подпрограмма RxPrepareToReparseSymbolicLink обычно вызывается мини-перенаправлением сети из процедуры обратного вызова MrxCreate .
Параметр SymbolicLinkEmbeddedInOldPath , переданный в эту подпрограмму, очень важен. Чтобы сохранить правильную семантику, ее следует использовать с осторожностью. Например, рассмотрим старый путь \A\B\C\D, где C является символьной ссылкой. В этом случае символьная ссылка внедряется в путь, а для параметра SymbolicLinkEmbeddedInOldPath должно быть задано значение TRUE. В отличие от этого, это сильно отличается от случая, когда D оказывается символьной ссылкой. В первом случае повторный обзор представляет собой промежуточный этап. Во втором примере повторный разбор представляет собой последний шаг разрешения имен, а для значения SymbolicLinkEmbeddedInOldPath должно быть задано значение FALSE.
Если указан доступ DELETE, операция открытия или создания запрещается во всех случаях, когда символьная ссылка не внедрена. Возможно, если только указан доступ DELETE, то открытая попытка должна завершиться успешно без повторного просмотра. Это соответствует семантике символьных ссылок UNIX.
В рамках этой процедуры RxContext также помечается соответствующим образом. Это гарантирует, что возвращаемое значение можно перекрестно проверить с вызовом этой подпрограммы. После вызова RxPrepareToReparseSymbolicLink мини-перенаправитель сети должен вернуть STATUS_REPARSE.
Значение параметра ReparseRequired принимает значение только в том случае, если STATUS_SUCCESS возвращается из этой подпрограммы. Если reparseRequired имеет значение FALSE, это означает, что попытка повторного обработки не требуется, а сам файл символьной ссылки следует манипулировать в отличие от целевого объекта ссылки. Если параметр ReparseRequired имеет значение TRUE, это означает, что попытка повторного выполнения была успешно настроена. В таких случаях крайне важно, чтобы мини-перенаправитель сети возвращал STATUS_REPARSE для связанного вызова MRxCreate . RDBSS инициирует проверка для этого условия.
Требования
Требование | Значение |
---|---|
Целевая платформа | Персональный компьютер |
Верхняя часть | rxprocs.h (включая Rxprocs.h) |
IRQL | <= APC_LEVEL |
См. также раздел
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по