CreateFile() 호출로 파일을 연 동안 사용할 수있는 여러 플래그와 속성 (dwFlagsAndAttributes)이 있습니다. 이러한 플래그 중 하나는 FILE_FLAG_SEQUENTIAL_SCAN입니다. 궁금하네요, 어떻게 든 감지 할 수 있습니다/파일 핸들이이 플래그를 사용하여 만든 여부를 유일한 핸들 자체 및 CreateFile 매개 변수에 대한 정보를 사용할 수있는 경우?FILE_FLAG_SEQUENTIAL_SCAN 플래그로 열린 파일 핸들이 있습니까?
커널 구조에서 NtQueryInformationFile (또는 ZwQueryInformationFile)을 호출하여 FILE_OBJECT 구조를 검색 할 수 있습니다. 그것의 깃발 회원은 당신이 찾고있는 정보를 제공합니다.
이것은 실제로 작동합니다. 정보 주셔서 감사합니다; 나는 혼자서 그곳에 다가 갈 수 없었다. 그럼에도 불구하고, 저는 우리가 똑같은 것을 말하고 있는지 확인하고 싶습니다. 어떤 FILE_OBJECT도 보이지 않지만 FILE_MODE_INFORMATION 구조에 플래그 FILE_SEQUENTIAL_ONLY (관심있는 CreateFile의 옵션)과 FILE_NO_INTERMEDIATE_BUFFERING (관심있는 옵션을 중립화하는) 플래그를 포함 할 수있는 모드 필드 (ULONG)가 포함되어 있습니다. 이게 당신이 의미 한 것이거나 제가 지적하고 싶었던 것을 놓친 것입니까? –
@ Mtm3.14 :'FILE_OBJECT' 구조체는 * wdm.h * 헤더 파일에 정의되어 있습니다. 'FO_SEQUENTIAL_ONLY' 플래그는'CreateFile' 호출의'FILE_FLAG_SEQUENTIAL_SCAN'에 해당합니다. 'FO_NO_INTERMEDIATE_BUFFERING'이 어떻게 작용하는지 모르겠습니다. – IInspectable
아마 ** 당신이 알아야 할 가장 흥미로운 플래그 일 것입니다. 캐시 관리자에게 힌트를 제공하는 것 이외에는 관찰 할 수있는 효과가없는 것입니다. 예를 들어'FILE_FLAG_OVERLAPPED'는 더 많이 알기에 재미있을 것입니다. 어쨌든, 당신은 정말로 어떤 문제를 해결하려고합니까? – IInspectable
때때로 관찰 가능한 효과는 관찰 지점에 달려 있습니다. :)이 플래그로 열린 파일에서 다시 읽으려는 시도는 특정 플랫폼에서 아주 잘 관찰 할 수있는 응용 프로그램 충돌을 일으 킵니다 (기본 계층에서 제공하는 최적화 수준에 따라이 플래그를 볼 수 있음). 브로커가 제어 할 수없는 파일을 열면 가장 효과적으로 데이터를 처리하기 위해 적용 할 알고리즘이 무엇인지 질문 할 수 있습니다 (버퍼링이 해결되지 않았 음을 제안합시다). –
이 플래그로 인해 충돌이 발생할 수있는 방법이 없어야합니다. 즉, Windows 또는 (더 가능성이 큰) 코드에서 버그를 의미합니다. 버그를 식별하고 해결하는 것이 더 좋을 것입니다. –