Разница в атрибутах при уничтожении объекта.

← →
Riply © (2007-11-10 01:40) [0]

Здравствуйте !
Реализация функций DeleteFile и RemoveDirectory очень похожи.
В обоих случаях используется NtCreateFile.
Но кроме логичных отличий в параметрах, есть разница в "SHARE" параметре.
Для DeleteFile ShareAccess устанавливается
FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE,
а для RemoveDirectory - ноль.
Поясните, пожалуйста, чем это обусловлено.

← →
guav © (2007-11-11 13:57) [1]

> а для RemoveDirectory - ноль.

На основании чего был сделан такой вывод ?
Я считаю что успешное выполнение нижеследующего кода опровергает этот вывод.
program Project2; {$APPTYPE CONSOLE} uses SysUtils, Windows; function OemSysErrorMessage(Error: Integer): string; var S: string; begin S := SysErrorMessage(Error); SetLength(Result, Length(S)); AnsiToOem(PChar(S), PChar(Result)); end; var hFile, hFile1: THandle; const sTestDir = "D:\test1"; begin // Create an empty folder. if not CreateDirectory(sTestDir, nil) then begin WriteLn("Unable to create test dir, error ", GetLastError()); WriteLn(OemSysErrorMessage(GetLastError())); ReadLn; Exit; end; // Open the folder with read and write access. hFile := CreateFile( sTestDir, GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE, nil, OPEN_ALWAYS, FILE_FLAG_BACKUP_SEMANTICS, 0); if INVALID_HANDLE_VALUE = hFile then begin WriteLn("Cannot open directory, error ", GetLastError()); WriteLn(OemSysErrorMessage(GetLastError())); ReadLn; Exit; end; // Open the folder again with exclusive share mode. // As it is already open with read and write access, // this should fail. hFile1 := CreateFile( sTestDir, GENERIC_READ, 0, nil, OPEN_ALWAYS, FILE_FLAG_BACKUP_SEMANTICS, 0); if INVALID_HANDLE_VALUE = hFile1 then begin WriteLn("Cannot open directory, error ", GetLastError()); WriteLn(OemSysErrorMessage(GetLastError())); end; try // Mark the folder for deletion. // As this succeedes, at least FILE_SHARE_READ and FILE_SHARE_WRITE // flags are specified inside the RemoveDirectory function. if not RemoveDirectory(sTestDir) then begin WriteLn("Cannot remove directory, error ", GetLastError()); WriteLn(OemSysErrorMessage(GetLastError())); ReadLn; Exit; end; WriteLn("The directory still exists"); WriteLn("Press any key..."); ReadLn; finally CloseHandle(hFile); end; WriteLn("Now it does not"); WriteLn("Press any key..."); ReadLn; end.

← →
Riply © (2007-11-11 14:28) [2]

> [1] guav © (11.11.07 13:57)
> На основании чего был сделан такой вывод ?

На основании следующего исходника:

BOOL WINAPI RemoveDirectoryW ( LPCWSTR ) 00520 { 00521 FILE_DISPOSITION_INFORMATION FileDispInfo; 00522 OBJECT_ATTRIBUTES ObjectAttributes; 00523 IO_STATUS_BLOCK IoStatusBlock; 00524 UNICODE_STRING NtPathU; 00525 HANDLE DirectoryHandle; 00526 NTSTATUS Status; 00527 00528 DPRINT("lpPathName %S\n", lpPathName); 00529 00530 if (!RtlDosPathNameToNtPathName_U (lpPathName, 00531 &NtPathU, 00532 NULL, 00533 NULL)) 00534 return FALSE; 00535 00536 InitializeObjectAttributes(&ObjectAttributes, 00537 &NtPathU, 00538 OBJ_CASE_INSENSITIVE, 00539 NULL, 00540 NULL); 00541 00542 DPRINT("NtPathU "%S"\n", NtPathU.Buffer); 00543 00544 Status = NtCreateFile (&DirectoryHandle, 00545 DELETE, 00546 &ObjectAttributes, 00547 &IoStatusBlock, 00548 NULL, 00549 FILE_ATTRIBUTE_DIRECTORY, /* 0x7 */ 00550 0, 00551 FILE_OPEN, 00552 FILE_DIRECTORY_FILE, /* 0x204021 */ 00553 NULL, 00554 0); 00555 00556 RtlFreeHeap (RtlGetProcessHeap (), 00557 0, 00558 NtPathU.Buffer); 00559 00560 if (!NT_SUCCESS(Status)) 00561 { 00562 CHECKPOINT; 00563 SetLastErrorByStatus (Status); 00564 return FALSE; 00565 } 00566 00567 FileDispInfo.DeleteFile = TRUE; 00568 00569 Status = NtSetInformationFile (DirectoryHandle, 00570 &IoStatusBlock, 00571 &FileDispInfo, 00572 sizeof(FILE_DISPOSITION_INFORMATION), 00573 FileDispositionInformation); 00574 NtClose(DirectoryHandle); 00575 00576 if (!NT_SUCCESS(Status)) 00577 { 00578 SetLastErrorByStatus (Status); 00579 return FALSE; 00580 } 00581 00582 return TRUE; 00583 }

> Я считаю что успешное выполнение нижеследующего кода опровергает этот вывод.
Код то выполняется успешно.
А вот выводы надо обдумать. "Что-то здесь не так" (с)

← →
guav © (2007-11-11 14:36) [3]

> [2] Riply © (11.11.07 14:28)

Это исходник Windows ?

← →
Riply © (2007-11-11 14:44) [4]

> [3] guav © (11.11.07 14:36)

> Это исходник Windows ?

Я еще (пока) не заслужила, что бы Microsoft давала мне исходники
по первому моему требованию, поэтому вынуждена обходиться ReactOS` овскими :)

← →
guav © (2007-11-11 14:53) [5]

> [4] Riply © (11.11.07 14:44)

Встречаются двое.
Один другому говорит:
- Не понимаю почему все так восхищаются этим Карузо? Слуха у него нет, голоса нет, картавит, шепелявит, пришептывает.
- Ооо! А вы слышали Карузо?
- Да нет. Мне Рабинович его вчера напел.

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

Если эту самую ReactOS можно запустить, можно проверить мой код там.

Ты наверное на таком же основании считаешь, что исходники драйвера NTFS у MS и линуксоидов одинаковые ? :-)

← →
Zeqfreed © (2007-11-11 15:00) [6]

Если выложите скомпилированный экзешник на файлопомойку какую-нибудь, то могу в виртуальной машине запустить его в ReactOS :)

← →
Riply © (2007-11-11 15:05) [7]

> [5] guav © (11.11.07 14:53)

:)

> Ты наверное на таком же основании считаешь,
> что исходники драйвера NTFS у MS и линуксоидов одинаковые ? :-)

Нет. Не считаю. :)
Но что они должны совпадать в ключевых идеологических моментах - мне кажется логичным.
А то как открывать на удаление - это важно. :)

← →
guav © (2007-11-11 15:08) [8]

> [6] Zeqfreed © (11.11.07 15:00)

Это хорошо. Предоставляю это Riply ©, может она захочет изменить код.

<off>

> [4] Riply © (11.11.07 14:44)

Есть прогресс со сложными случаями в MFT ?
</off>

← →
Riply © (2007-11-11 15:15) [9]

> [8] guav © (11.11.07 15:08)

> Это хорошо. Предоставляю это Riply ©, может она захочет изменить код.

Наверное менять не буду. Куда лучше выложить ?

<off>
> [4] Riply © (11.11.07 14:44)
> Есть прогресс со сложными случаями в MFT ?
Продвигается, но медленно.
Трудно добиться стабильности возникновения "нестандартного случая",
что бы заявить: "после таких-то и таких-то действий, имеем то-то и то-то" :)

</off>

← →
Zeqfreed © (2007-11-11 15:17) [10]

> Riply © (11.11.07 15:15) [9]

Да хоть куда :) filesurf.ru, например.
Можно и на почту послать. zeqfreed@gmail.com

← →
guav © (2007-11-11 15:20) [11]

> Но что они должны совпадать в ключевых идеологических моментах
> - мне кажется логичным.

В подобных "идеологических" мометах исходники Майкрософт не всегда совпадают с мнением, изложенным в MSDN.
Что уж говорить об исходниках, не от Майкрософт.

Попробуй "поотлаживать" саму ntdll, если сабж действительно интересует.

> Трудно добиться стабильности возникновения "нестандартного
> случая",
> что бы заявить: "после таких-то и таких-то действий, имеем
> то-то и то-то" :)

Тогда образ на почту, Windows поддерживает NTFS с 8 МБ, а если форматировать нестандартными утилитами, то ещё меньше. Детали обсудить можно тоже по почте. Кстати, если дело касаестя разреженных или сжатых, опиши заранее, бо может это я уже видел.

← →
Riply © (2007-11-11 15:20) [12]

> [10] Zeqfreed © (11.11.07 15:17)

http://slil.ru/25087818

← →
Riply © (2007-11-11 15:27) [13]

> [11] guav © (11.11.07 15:20)

>Попробуй "поотлаживать" саму ntdll, если сабж действительно интересует.

САБЖ интересует, ибо прежде чем самой соваться в MFT, как "слону в посудную лавку",
иногда бывает не вредно посмотреть, как это делают другие :)

> Тогда образ на почту, Windows поддерживает NTFS с 8 МБ,
> а если форматировать нестандартными утилитами, то ещё меньше.
Хорошо. Подготавливаю и высылаю.

← →
Zeqfreed © (2007-11-11 15:45) [14]

Что-то не получается у меня :(
Буду еще пытаться. Если получится сообщу :)

← →
guav © (2007-11-11 15:46) [15]

Там хоть в бинарнике hardcoded "D:\test1" именено на ReadLn ?

Фуф. Получилось наконец закинуть файл на виртуальную машину :)

После запуска выдает:

Cannot open directory, error 32 ERROR SHARING VIOLATION - The process cannot access the file because it is being used by another process Cannot remove directory, error 32 ERROR SHARING VIOLATION - The process cannot access the file because it is being used by another process

> [18] Zeqfreed © (11.11.07 16:06)

Спасибо.
3начит сабж есть специфика ReactOS и не имеет отношения к поведению Windows XP.

> guav © (11.11.07 16:25) [19]

Да, видимо так. Можно даже, наверное, сообщить об этом команде разработчиков — возможно, это не было их сознательным решением.

> [19] guav © (11.11.07 16:25)
> 3начит сабж есть специфика ReactOS и не имеет отношения к поведению Windows XP.

> [20] Zeqfreed © (11.11.07 18:45)
> Да, видимо так. Можно даже, наверное, сообщить об этом команде
> разработчиков — возможно, это не было их сознательным решением.

Ребят, спасибо огромное за помощь и
"сампожертванное написание и тестирование кода" :)

Я не успокоилась и чутка "поперехватывала" Nt - ф-ии.
Со своей стороны добавлю, что под Windows RemoveDirectoryW
NtCreateFile вовсе и не вызывает :)
Она обходится NtOpenFile` ом, передавая ему в качестве ShareAccess
FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE.
Так что прав был guav, заподозрив липу в сабжевом вопросе :)

P.S.
Очень полезная ветка.
Из нее я выяснила, что не стоит делать заключения о Карузо,
базируясь только на знании Рабиновича :)
А это ценное знание для программиста :)

Разница в атрибутах при уничтожении объекта. Найти похожие ветки