Делаю следующим образом:

    // opening the target file for write
    InitializeObjectAttributes( &objAttributes, &fileName, 
                                OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, 
                                NULL, NULL);

    status = ZwOpenFile(&targetFileHandle, GENERIC_WRITE | GENERIC_READ | SYNCHRONIZE, &objAttributes, 
                                &ioStatus, FILE_SHARE_READ | FILE_SHARE_WRITE, 
                                FILE_SEQUENTIAL_ONLY | FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT);

    ...

    PFILE_RENAME_INFORMATION    renameInfo = NULL;

    ....

    renameInfo->ReplaceIfExists = TRUE;
    renameInfo->RootDirectory = NULL;
    renameInfo->FileNameLength = ...

    RtlCopyMemory(  &renameInfo->FileName[0], // только новое имя ('newname.ext')
                    destFileNamePtr,
                    renameInfo->FileNameLength);

    status = ZwSetInformationFile(  targetFileHandle, &ioStatus, 
                                    renameInfo, renameInfoLength, FileRenameInformation);

когда таким образом переименовывается файл на локальном диске (что-нить типа C:\file.ext) — все работает ok.
Но если переименованный файл лежит на сетевой шаре (\??\UNC\Computer\share\file.ext) ZwSetInformationFile виснет намертво.

Есть какие-то ньюансы с переименованием такого файла?

Здравствуйте, Ulin, Вы писали:

Вообще действие происходит в моем minifilter driver. Переименование происходит в системном потоке, созданном моим драйвером. Дебагер показал, что NtSetFileInformation повисает сразу после выполнение IoCallDriver (переименование в этот момент происходит успешно) на WaitForMutexObject. Судя по комментам в исходнике там идет ожидание завершения операции, которого по каким-то причинам не происходит, почему-то получается deadlock.
В моем callback'e для IRP_MJ_SET_INFORMATION я игнорирую I/O от моего системного потока. В callback PreCreate при переименовании ничего не приходит.

Здравствуйте, Ulin, Вы писали:

U>Здравствуйте, Ulin, Вы писали:

U>Вообще действие происходит в моем minifilter driver. Переименование происходит в системном потоке, созданном моим драйвером. Дебагер показал, что NtSetFileInformation повисает сразу после выполнение IoCallDriver (переименование в этот момент происходит успешно) на WaitForMutexObject. Судя по комментам в исходнике там идет ожидание завершения операции, которого по каким-то причинам не происходит, почему-то получается deadlock.

Похоже, доставка APC запрещена в момент выполнения операции. См. Disabling APCs в DDK. Тут необходимо учитывать, что заключительная фаза завершения ввода-вывода выполняется в виде special kernel APC.