KR100868410B1

KR100868410B1 - 관리화된 파일 시스템 필터 모델 및 아키텍쳐

Info

Publication number: KR100868410B1
Application number: KR1020030088524A
Authority: KR
Inventors: 라비산카르 푸디페디; 에일린씨. 브라운; 닐 크리스티안센; 라빈더 씬드; 브리안케이. 데웨이; 다비드피. 골드스; 마크제이. 즈비코우스키
Original assignee: 마이크로소프트 코포레이션
Priority date: 2002-12-09
Filing date: 2003-12-08
Publication date: 2008-11-11
Also published as: MXPA03011280A; AU2003266438A1; CN100504764C; RU2335796C2; JP2004192648A; US20060136460A1; JP3974892B2; BRPI0305401B1; KR20040050855A; CA2450044A1; EP1429247B1; RU2003135656A; US20040111389A1; EP1429247A2; EP1429247A3; CN1508679A; AU2003266438B2; US7779425B2; CA2450044C; US6993603B2

Abstract

필터 드라이버가 관심을 갖는 I/O 요구용 콜백을 수신하도록 필터 드라이버가 관리되는 모델을 개시한다. 필터 드라이버의 퍼-볼륨 인스턴스는 (파일 시스템에 대한 I/O를 위해) 프리-콜백용 필터 매니저로 등록을 행하고, (파일 시스템으로부터의 I/O를 위해) 포스트-콜백을 행하며, 콜백을 수신하기 위해 어느 I/O 요구를 등록하고 있는지를 식별한다. 필터 매니저는 콜백용 인스턴스를 순서화한다. I/O 요구가 수신되면, 필터 매니저는 그 I/O 요구를 콜백 데이터로 변환하고 콜백 오더에서 관심 대상인 필터를 호출하며, 이에 따라 그 필터 인스턴스는 I/O 데이터를 처리할 수 있다. 그 요구가 파일 시스템으로부터 리턴되면, 포스트-콜백을 원하는 필터는 역순으로 호출된다. 필터, 및 비 재진입성(non-reentrant) 파일 I/O 등의 다른 기능에 대하여 효율적인 컨텍스트 관리가 그 모델에 의해 제공된다.

필터 드라이버, 상태 데이터, 파일 시스템, 프리-콜백

Description

관리화된 파일 시스템 필터 모델 및 아키텍쳐{MANAGED FILE SYSTEM FILTER MODEL AND ARCHITECTURE}

도 1은 일반적으로 본 발명이 구현되는 컴퓨터 시스템을 나타내는 블록도.

도 2는 일반적으로 본 발명의 일 양태에 따라 필터에 대한 I/O를 관리하기 위한 구성 요소를 포함하는 아키텍쳐를 나타내는 블록도.

도 3은 일반적으로 본 발명의 일 양태에 따라 관리화된 필터의 인스턴스를 나타내는 블록도.

도 4는 일반적으로 본 발명의 일 양태에 따라 I/O를 등록된 레지스터에 적절하게 선택적으로 전달하는 필터 매니저에 의해 사용되는 데이터 구조를 나타내는 블록도.

도 5는 본 발명의 일 양태에 따라 포스트-콜백 연산에서 콜백 데이터를 등록된 필터 드라이버에 리턴하기 위한 완료 노드의 스택을 나타내는 도면.

도 6은 본 발명의 일 양태에 따라 컨텍스트 데이터를 갖는 인스턴스에서의 효율적인 결정을 위한 트리를 나타내는 블록도.

도 7은 본 발명의 일 양태에 따라 컨텍스트 데이터를 필터 드라이버에 리턴하는 것을 나타내는 블록도.

* 도면의 주요 부분에 대한 부호 설명 *

110 컴퓨터

120 처리 유닛

121 시스템 버스

131 ROM

132 RAM

136 어플리케이션 프로그램

137 프로그램 모듈

138 프로그램 데이터

141 하드 디스크 드라이브

151 자기 디스크 드라이브

152 비휘발성 자기 디스크

본 발명은 일반적으로 컴퓨터 시스템에 관한 것으로서, 보다 상세하게는 파일 시스템 및 파일 시스템 필터에 관한 것이다.

Windows

NTFS(Windows

NT File System), FAT, CDFS, SMB 리디렉터 파일 시스템, 또는 WebDav 파일 시스템과 같은 기초 파일 시스템을 갖는 Microsoft Corporation사의 Windows

XP 운영 시스템과 같은 최신 운영 시스템에서, 하나 이상의 파일 시스템 필터 드라이버는 사용자 I/O 요구를 수신하는 I/O 매니저와 파일 시스템 드라이버 사이에 삽입될 수 있다. 일반적으로, 필터 드라이버(즉, '필터'라 칭함)는, 파일 시스템 I/O(요구 및 데이터)를 안티-바이러스 소프트웨어, 파일 시스템 쿼터 제공자, 파일 레플리케이터, 및 암호화/압축화 제품에 의해 전달하는 것과 같은 작업을 포함하여, 사용자가 원하는 다양한 파일 관련 컴퓨팅 작업을 수행함으로써 기초 파일 시스템을 향상시키는 커널 모드 드라이버이다. 예를 들어, 안티-바이러스 제품은 바이러스 시그너쳐를 검색하기 위해 소정의 파일 종류(예를 들어, .exe, .doc 등)에 대한 I/O를 감시하는 필터를 제공하는 반면, 파일 레플리케이션 제품은 파일 시스템-레벨 미러링을 수행한다. 다른 종류의 파일 시스템 필터 드라이버는 (변경이 발생할 때 시스템 파일을 백업하여 사용자가 원래 상태로 되돌릴 수 있는) 시스템 복구, 디스크 쿼터 강화, 오픈 파일의 백업, 삭제된 파일의 복원, 파일 암호화 등에 관한 것이다. 따라서, 파일 시스템 필터 드라이버를 설치함으로써, 컴퓨터 사용자는, 실제 운영 시스템 또는 파일 시스템 드라이버 코드를 변경할 필요 없이 구성 요소의 업그레이드, 대체, 삽입, 소거가 가능한 방식으로, 필요로 하는 파일 시스템 특징을 선택할 수 있다.

최신의 Windows

계열 운영 시스템(예를 들어, Windows

NT, Windows

2000, Windows

XP, Windows

.NET Server 2003)에서 현존하는 파일 시스템 필터 모델은, 패킷에 기초한 방식인 고유 I/O 모델을 채용한다. 이러한 점을 달성하기 위해, 파일 시스템 필터는 일반적인 드라이버로서 스택 내에 로드되어 기초 파일 시스템의 볼륨 장치 오브젝트에 부가된다.

사용자 I/O 요구는 I/O 매니저에 의해 I/O 요구 패킷(IRP)으로 변환되며, 이 것은 드라이버 스택에 전송되어 탑 드라이버에 의해 처리되고, 탑 드라이버는 그 처리를 완료하여 파일 시스템을 향하여 호로서 다른 드라이버에 전달하며, 이 파일 시스템은 그 다음 하위 드라이버를 호출하고, 계속 이러한 방식으로 진행된다. 일반적으로, 각 드라이버는 IPR 상에서 수행하기 위해 코딩되는 어떠한 처리도 수행하고, 이후 그 IRP를 그 다음 하위 드라이버 (또는 더 이상의 하위 드라이버가 없다면 파일 시스템)에 명시적으로 전달하고, 또는 IPR를 완료(또는 실패)하여 다시 스택 위에 두어 그 다음 상위 드라이버 (또는 더 이상의 상위 드라이버가 없다면 I/O 매니저)에 다시 전송한다.

현존하는 이러한 필터 드라이버 모델은 상당히 유연하다는 이점을 비롯하여 많은 이점을 제시하지만, 이와 관련된 고유의 문제점이 상당히 많다. 일 예를 들면, 파일 시스템 필터에 기록하는 것은 파일 시스템의 근본적인 복잡성으로 인해 비단순(non-trivial) 작업이다. 필터는 전통적으로 디버깅 및 유지가 힘든 매우 복잡한 소프트웨어의 일부이다. 필터의 패킷 처리, 예를 들어, IPR를 이해하고 조작할 필요로 인해 많은 복잡성이 발생한다. 그 결과, 신뢰성이 저하되며, 그리고 하나 이상의 연구 결과에 따르면 필터가 시스템 충돌의 상당한 퍼센트를 차지함을 알 수 있었다.

다른 문제점은 효율성에 관한 것으로서, 파일 시스템 필터가, 아무런 관계를 갖지 않음에도 불구하고, 전통적으로 파일 시스템으로 진행되는 모든 연산을 수신 및 처리한다는 점이다. 예를 들어, 안티바이러스 제품은 60퍼센트만큼 시스템을 느리게 할 수 있지만, 안티바이러스 필터에 의해 수신되는 모든 I/O 요구는, 이 요구에 의해 필터가 어떠한 것이든 수행하려는, 즉, 바이러스에 해당하는 임의의 데이터를 검사하려는 요구가 아니다. 리던던시도 비효율성과 컴퓨팅 비용을 야기하는 문제점으로서, 많은 밀터가 동일한 작업을 다른 방식으로 하기 때문에, 불필요한 코드가 야기된다.

드라이버 간의 상호 운용성도 주요 문제점으로서, 예를 들어, 하나의 드라이버가, 다른 드라이버가 예상하지 못하고 적절히 대처할 수 없는 방식으로 I/O를 수정할 수 있다. 상호 운용성 문제는 현존하는 모델이 갖는 가장 큰 단점들중 하나이며, 이것은 부분적으로는 파일 시스템으로의 부가 순서화에 대하여 필터가 대략적인 제어밖에 수행하지 못하기 때문임을 주목하기 바란다.

다른 문제점으로는 오버플로우 스택 공간이 있으며, 그 이유는 2개 이상의 필터가 설치되어 있을 때 필터에 의해 발생되는 순환 재진입성 I/O로 인해 스택 오버플로우가 발생하기 때문이다. 데드록도 현존하는 모델에서의 공통적인 문제점이며, 이것도 역시 재진입 I/O로 인해 발생한다. 또다른 문제점으로는 스택 내에 필터를 동적으로 로드 및 언로드할 수 없다는 점, 즉 시스템 리부팅없이 수행할 수 없다는 것이다.

요약하면, 현존하는 필터 드라이버 모델은 많은 단점을 갖고 있다. 파일 시스템 필터가 파일 시스템 I/O 요구 및 관련 데이터를 처리할 수 있는 개선된 모델 및 아키텍쳐가 필요하다.

본 발명은, 필터 드라이버가 관심을 갖은 I/O 요구용 콜백을 수신하도록 필터 매니저에 의해 필터 드라이버가 관리되는 모델/아키텍쳐를 제공한다. IRP, 패스트 I/O 경로, Fs 필터 콜백 등이, 필터 내에 명시적이며 뚜렷한 포맷을 제공하는 콜백 데이터를 제공하는 콜백으로 필터 매니저에 의해 번역되는 관리화된 콜백 모델을 제공함으로써, 이 모델에서는 전통적인 복잡한 I/O 전달이 필요없다. 필터는 필요시 콜백 데이터를 조작하고, 후술하는 바와 같이 그 콜백에 응답하여 상태를 리턴한다. 그 결과로, 필터는 더 이상 IRP를 처리할 필요가 없다.

일반적으로, 필터 매니저는 I/O, 즉, IRP, 패스트 I/O, FS 필터 콜백 등을 '콜백 데이터'로 알려진 균일한 구조로 번역한다. 이것을 달성하기 위해, 필터 매니저는 자신이 레거시 필터 드라이버인 것처럼 레거시 필터 드라이버 스택 내에 배치되어도 되며, 이에 따라 IRP를 수신 및 처리할 수 있다. 이후, 필터 매니저는 적절히 등록된 필터 드라이버의 리스트를 살펴 등록된 I/O용 디스패치를 기동한다.

필터 드라이버는, 필터 매니저에서 등록 메카니즘으로 레지스터를 구현할 때의 오브젝트(또는 이와 유사한 구성 요소)를 포함하여도 된다. 필터 드라이버는, 관심 대상인 I/O 요구 종류(예를 들어, 생성, 판독, 기록, 종료 등)를 필터 매니저에게 통지함으로써, 처리에 관련될 수 있는 파일 시스템 요구에 대해서만 등록한다. 그 결과로, 그 모델은, 필터 드라이버가 관심을 갖지 않는 I/O 요구를 보지 않고 이에 따라 그 요구를 등록하지 않았기 때문에, 스택형 필터 모델보다 효율적이다.

일 예로서, 복수의 필터 드라이버는 볼륨 단위로 필터 드라이버 인스턴스로 서 볼륨에 별도로 부가되며, 하나의 필터 드라이버는 여러 인스턴스를 동일한 볼륨에 부가하여도 된다. 각 필터 드라이버 인스턴스는 '고도'와 관련되며, 이 고도는 콜백 오더에서 그 드라이버가 어디에 위치하는지를 나타낸다. 고도는 미리 규정되어도 되고, 또는 드라이버가 콜백 데이터 상에서 수행할 처리의 종류를 나타내는 그 드라이버에 의해 제공되는 플래그로부터 유도되어도 된다.

어느 필터 드라이버가 어떤 콜백 종류를 등록하였는지를 효율적으로 추적하고 이에 따라 적절한 순서로 적절한 드라이버를 효율적으로 콜백하기 위해, 필터 매니저는 볼륨 단위로 순서화된 리스트를 유지하며, 각 리스트는, 프리-콜백 및/또는 포스트-콜백을 수신하는데 관심을 보인 필터의 연산 종류에 의해 인덱스된다. 필터 매니저는 이 리스트를 이용하여 필터를 적절한 순서로 콜백하고, 각 필터는 상태를 리턴한다. 성공적이다고 가정하면, 최종 프리-콜백에 이어, 필터 매니저는 콜백 데이터를 IRP로 재변환하여 그 IRP를 파일 시스템에 전송한다.

포스트-콜백동안 필터가 스킵되도록 표시할 수 있지만, 포스트-콜백은 본질적으로 역순으로 동작한다. I/O 완료는, 자신의 프리-콜백에서 필터 인스턴스에 의해 보이는 파라미터가 자신의 포스트-콜백에서의 파라미터와 동일함을 보장하는 방식으로 필터 매니저에 의해 조작된다. 이것을 달성하기 위해, 필터 매니저는, 각 포스트-콜백에서 정확한 파라미터를 리턴하기 위해 완료 노드 스택에 액세스하는 이 완료 노드 스택을 유지한다.

필터 매니저는, 필터가 공통적으로 필요로 하는 기능을 제시하는 리치 API 세트를 또한 제공한다. 예를 들어, 소정의 필터는 필터 고유의 I/O를 수행할 필요 가 있으며, 이러한 연산을 용이하게 하는 다양한 기능이 제공된다. 다양한 기능에는 적절한 오브젝트와 관련하여 각 필터용 컨텍스트 데이터를 추적하는 스트림, 인스턴스, 볼륨, 파일, 또는 스트림 핸들을 갖는 효율적인 컨텍스트 지원이 또한 포함된다.

본 발명은 엔티티용 통지를 설정하는 한 세트의 콜백을 통한 통지 지원을 제공하며, 퍼-필터 컨텍스트와 그 엔티티와의 연관성을 간략화한다. 컨텍스트는 언제라도 설정 및/또는 리셋될 수 있다. 또다른 기능에 의해 커널 모드 필터 드라이버와, 사용자 모드 카운터파트 서비스 및 프로그램 간의 통신이 가능해지는 한편, 또다른 기능에 의해서는 2002년 8월 28일 출원한 미국 특허출원번호 10/187119에 기재된 바와 같은 지원을 지정한다.

다른 이점들은 도면을 참조하여 다음의 상세한 설명에 의해 자명해질 것이다.

<실시예>

운영 환경

도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템(100)의 일 예를 도시한다. 이 컴퓨팅 시스템(100)은 적절한 컴퓨팅 환경의 일 예일 뿐이며 본 발명의 기능성 또는 이용 범위를 제한하지 않는다. 운영 환경(100)에 도시된 구성 요소들중 임의의 하나 또는 이들의 조합과 관련된 의존성 또는 요구 사항을 갖는 것으로서 컴퓨팅 환경(100)을 해석해서는 안된다.

본 발명은 다수의 다른 범용 또는 전용 컴퓨팅 시스템 환경 또는 구성에 따 라 동작가능하다. 본 발명에서 이용하기에 적절한 것으로 알려져 있지만 다음의 예로 한정되지 않은 컴퓨팅 시스템, 환경, 및/또는 구성으로는, 퍼스널 컴퓨터, 서버 컴퓨터, 수동 또는 랩탑 장치, 태블릿 장치, 멀티프로세서 시스템, 마이크로프로세서계 시스템, 셋톱 박스, 프로그래밍가능한 소비재, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기한 시스템 또는 장치중 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 있다.

본 발명은 프로그램 모듈과 같이 컴퓨터로 실행가능한 명령의 일반적인 컨텍스트로 기재되어도 된다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 오브젝트, 구성 요소, 데이터 명령 등을 포함하며, 특정 작업을 수행하거나 특정한 요약 데이터 종류를 구현한다.

또한, 본 발명은, 통신 네트워크를 통해 링크되는 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시되어도 된다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 원격 컴퓨터 저장 매체 및 로컬 컴퓨터 저장 매체 모두에 배치하여도 된다.

도 1을 참조하면, 본 발명을 구현하기 위한 시스템이 범용 컴퓨팅 장치를 컴퓨터(110)의 형태로 포함하고 있다. 컴퓨터(110)의 구성 요소는, 처리 유닛(120), 시스템 메모리(13), 및 시스템 메모리를 포함하는 다양한 시스템 구성 요소를 처리 유닛(120)에 커플링하는 시스템 버스(121)를 포함하여도 되지만, 이러한 예로 한정되지 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기를 포함하는 여러 종류의 버스 구조, 주변 버스, 및 다양한 버스 구조중 임의의 것을 이용하는 로 컬 버스중 임의의 것이어도 된다. 예를 들어, 물론 이러한 예에 한정되지는 않지만, 그러한 아키텍쳐에는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA), VESA(Video Electronics Standards Association) 로컬 버스, 및 Mezzanine 버스로도 알려진 PCI(Peripheral Component Interconnect) 버스가 있다.

컴퓨터(110)는 전형적으로 다양한 컴퓨터로 판독가능한 매체를 포함한다. 컴퓨터로 판독가능한 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며 휘발성 매체와 비휘발성 매체 모두, 및 소거가능한 매체와 소거불가능한 매체를 포함한다. 예를 들어, 이 예에 한정되지는 않지만, 컴퓨터로 판독가능한 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하여도 된다.

컴퓨터 저장 매체는, 컴퓨터로 판독가능한 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터처럼 정보 저장을 위한 임의의 방법 또는 기술에 의해 구현되는, 휘발성 매체와 비휘발성 매체 모두, 및 소거가능한 매체와 소거불가능한 매체를 포함한다. 컴퓨터 저장 매체로는, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD, 또는 다른 광 디스크 저장매체, 자기 카세트, 자기 테이프, 자기 디스크 저장매체 또는 다른 자기 저장매체, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 다른 임의의 매체를 예로 들 수 있으며, 이러한 예로 한정되지 않는다. 통신 매체는, 전형적으로 컴퓨터로 판독가능한 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 반송파 또는 트랜스포트 메카니즘과 같은 다른 조정된 데이터 신호로서 구현하며, 임의의 정보 전달 매체를 포함한다.

'조정된 데이터 신호"라는 용어는 하나 이상의 특성 세트를 갖는 신호 또는 그 신호내의 정보를 인코딩하는 방식으로 변경된 신호를 의미한다. 예를 들어, 통신 매체로는 유선 네트워크 또는 직접 유선 접속과 같은 유선 매체, 어쿠스틱, RF, 적외선 및 다른 무선 매체와 같은 무선 매체가 있으며, 이러한 예로 한정되지 않는다. 상기한 구성 요소들의 임의의 조합도 컴퓨터로 판독가능한 매체의 범위내에 있다.

시스템 메모리(130)는, ROM(131) 및 RAM(132)과 같은 휘발성 및/또는 비휘발성 메모리의 형태인 컴퓨터 저장 매체를 포함한다. 시동 동안처럼 컴퓨터(110)내의 소자 간에 정보를 전송하는데 도움이 되는 기본 루틴을 포함하는 BIOS(133)는, 전형적으로 ROM(131)내에 저장된다. RAM(132)은 전형적으로 처리 유닛(120)에 의해 현재 연산되고 있는 그리고/또는 즉시 액세스가능한 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들어, 도 1은 운영 시스템(134), 파일 시스템(135), 어플리케이션 프로그램(136), 다른 프로그램 모듈(137), 및 프로그램 데이터(138)를 도시하며, 이러한 예로 한정되지 않는다.

또한, 컴퓨터(110)는 다른 소거가능한/소거불가능한 컴퓨터 저장 매체, 휘발성/비휘발성 컴퓨터 저장 매체를 포함하여도 된다. 예를 들면, 도 1은, 소거불가능한 비휘발성 자기 매체를 판독 또는 기록하는 하드 디스크 드라이브(141), 소거가능한 휘발성 자기 디스크(152)를 판독 또는 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 다른 광 매체와 같이 소거가능한 비휘발성 광 디스 크(156)를 판독 또는 기록하는 광 디스크 드라이브(155)를 도시한다. 예시적인 운영 환경에서 사용될 수 있는 다른 소거가능한/소거불가능한 휘발성/비휘발성 컴퓨터 저장 매체는, 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 RAM, 고체 ROM, 등을 포함하지만, 이러한 예로 한정되지 않는다. 하드 디스크 드라이브(141)는 전형적으로 인터페이스(140)와 같은 비휘발성 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 전형적으로 인터페이스(150)와 같은 소거가능한 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

도 1에 도시되어 있으며 상기한 드라이브 및 이 드라이브과 관련된 컴퓨터 저장 매체는, 컴퓨터로 판독가능한 명령, 데이터 구조, 프로그램 모듈, 및 컴퓨터용 다른 데이터를 저장한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로서 도시되어 있다. 이러한 구성 요소는 운영 시스템(134), 어플리케이션 프로그램(136), 다른 프로그램 모듈(137), 및 프로그램 데이터(138)와 동일하거나 다를 수 있다는 것을 주목하길 바란다. 운영 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 이들이 다른 구성 요소임을 나타내기 위해 다른 부재 번호를 갖는다.

사용자는, 태블릿(전자 디지타이저; 164), 마이크로폰(163), 키보드(162), 및, 흔히 마우스, 트랙볼 또는 터치패드라 칭하는 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)내에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(도시하지 않음)로는 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 있다. 이러한 입력 장치 및 다른 입력 장치는, 흔히 시스템 버스에 커플링되는 사용자 입력 인터페이스(160)를 통해 처리 유닛(120)에 접속되지만, 병렬 포트, 게임 포트, 또는 USB와 같은 다른 인터페이스 및 버스 구조에 의해 접속되어도 된다. 모니터(191) 또는 다른 종류의 표시 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다.

모니터(191)는 터치 스크린 패널 등과 함께 집적되어도 된다. 모니터 및/또는 터치 스크린 패널은 태블릭형 퍼스널 컴퓨터내에서와 같이 컴퓨팅 장치(110)가 내장되어 있는 하우징에 물리적으로 결합될 수 있다는 것을 주목하길 바란다. 또한, 컴퓨팅 장치(110)와 같은 컴퓨터는, 출력 주변 인터페이스(194) 등을 통해 접속될 수 있는, 스피커(195) 및 프린터(196)와 같은 다른 주변 출력 장치를 더 포함하여도 된다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터에 대한 논리 접속을 이용하여 네트워크화 환경에서 동작할 수 있다. 원격 컴퓨터(180)는, 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치, 또는 다른 공통 네트워크 노드이어도 되며, 전형적으로 컴퓨터(110)에 비해 상기한 소자들의 상당 부분 또는 소자 모두를 포함하지만, 도 1에는 단지 하나의 메모리 저장 장치(181)만이 도시되어 있다.

도 1에 도시된 논리 접속에는 LAN(171), 및 WAN(173)이 있지만, 다른 네트워 크도 가능하다. 이러한 네트워킹 환경은 사무실, 기업규모 컴퓨터 네트워크, 인트라넷, 및 인터넷에서 흔한 것이다. 예를 들어, 본 발명에서, 컴퓨터 시스템(110)은 데이터가 이동되는 소스 머신을 포함하여도 되고, 원격 컴퓨터(180)는 데스티네이션 머신을 포함하여도 된다. 소스 및 데스티네이션 머신은 네트워크 또는 다른 임의의 수단에 의해 접속될 필요가 없지만, 데이터는 소스 플랫폼에 의해 기록될 수 있고 데스티네이션 플랫폼 또는 복수의 데스티네이션 플랫폼에 의해 판독될 수 있는 임의의 매체를 통해 이동될 수 있다는 것을 주목하길 바란다.

컴퓨터(110)를 LAN 네트워킹 환경에서 이용할 때, 컴퓨터(110)는 네트워크 인터페이스 또는 아답터(170)를 통해 LAN(171)에 접속된다. 컴퓨터(110)를 WAN 네트워킹 환경에서 이용할 때, 컴퓨터(110)는 전형적으로 모뎀(172) 또는 WAN(173)을 이용하는 통신을 확립하기 위한 다른 수단을 포함한다. 내장형 또는 외장형인 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메카니즘을 통해 시스템 버스(121)에 접속되어도 된다. 네트워크화된 환경에서, 컴퓨터(110)에 대하여 표현된 프로그램 모듈, 또는 그 일부는 원격 메모리 저장 장치 내에 저장되어도 된다. 예를 들어, 도 1은 메모리 장치(181) 상에 상주하는 원격 어플리케이션 프로그램(185)을 도시하고 있지만, 이러한 예로 한정되지 않는다. 도시된 네트워크 접속은 일예이며 컴퓨터 간의 통신을 확립하는 다른 수단을 이용하여도 된다는 것을 이해하게 될 것이다.

관리화된 파일 시스템 필터 모델 및 아키텍쳐

본 발명은, 일반적으로 다양한 시스템 관련 제품 간의 상호 운용성을 용이하 게 하는 것을 포함하여 필터에 의한 파일 시스템 I/O 핸들링을 개선하는, 파일 시스템 필터 모델 및 아키텍쳐에 관한 것이다. 이 모델은 일반적으로 I/O 매니저와 로컬 또는 원격 파일 시스템인 베이스 파일 시스템 사이에서 동작하는 필터 드라이버를 참조하여 설명되며, 파일 시스템과 (FtDisk또는 DMIO와 같은) 저장 드라이버 또는 복수의 드라이버 사이에서 동작하는 필터 드라이버를 포함하여 다른 드라이버를 참조하여 설명되지 않는다는 것을 주목하길 바란다.

여기서, "레거시" 필터 드라이버는, 후술하는 바와 같이 등록된 필터 드라이버에 대한 콜백을 이용하는 새로운 모델에 의해서가 아니라 기존의 방식대로 I/O 요구 패킷(IRP)을 다루는 것이다. 레거시 필터 드라이버가 시간이 흘러감에 따라 페이즈 아웃되는 것을 예상할 수 있듯이, 새로운 등록에 따르는 필터 드라이버 및 콜백 모델은 본 명세서에서 간략하게 "필터 드라이버"라 칭한다.

새로운 필터 모델의 주요 양태중 하나는, 레거시 필터로부터 스택 모델을 통해 레거시 필터로의 기존의 복잡한 I/O 전달을 제거하고, 그 모델을 관리화되는 콜백 모델로 대체한다는 것이며, 이 대체되는 모델에서 IRP, 패스트 I/O 경로, 메모리 매니저 콜백 등은, 필터 매니저에 의해, 규정 포맷으로 데이터를 필터 내에 제공하는 콜백으로 번역된다. 이 필터는, 다른 필터들을 호출하거나 제어를 다른 필터에 직접 전달하지 않으며, 후술하는 바와 같이 필요할 때 그 콜백 데이터를 조작하고, 그 콜백에 응답하여 상태를 리턴한다. 필터는 더 이상 IRP 등을 다룰 필요가 없기 때문에, 그 필터로부터 I/O 핸들링의 복잡성이 상당히 제거되어 하나의 필터 매니저 내에 내장되며, 이에 따라 다양한 필터에 의해 야기되는 많은 문제점을 제거하게 된다. 예를 들어, IRP는, 흔히 레거시 필터 드라이버가 정보를 다루는데 있어서 예전부터 어려움을 겪어왔던 암시적이고 복잡한 그 정보를 포함한다. 본 발명은 필터 매니저가 암시적 정보를 다루게 하여 명시적인 컨텍스트만을 필터에 전달하게 함으로써 그러한 문제점을 제거한다. 콜백 모델은 스택 오버플로우를 해결하고 연쇄형 IRP 디스패치로 인해 발생하는 이슈들을 억제하는 이점을 더 갖고 있다.

도 2는 새로운 모델(200)의 일 예를 도시한다. 도 2에 도시된 모델의 한가지 이점은, 기존의 어플리케이션, 운영 시스템, 구성 요소 및 파일 시스템이 그 새로운 모델을 구현하기 위해 어떠한 방식으로도 수정될 필요가 없다는 것이다. 예를 들어, Windows

계열 운영 시스템에서, 어플리케이션(202)은 API층(204)을 통해 여전히 파일 시스템 요구를 I/O 매니저(206)에 대하여 만들 것이다(예를 들어, 기능/방법 호를 통해서임). 이미 알려져 있듯이, I/O 매니저(206)는 IRP 또는 다른 종류의 I/O를 생성하며, 그 I/O를 (레거시) 필터 드라이버 스택(208)의 최상위에 전송한다. 후술하는 바와 같이, 스택(208) 내의 구성 요소중 하나는 필터 매니저(212)이다.

일반적으로, 필터 매니저(212)는 I/O, IRP, 패스트 I/O, FS 필터 콜백 등을 콜백 데이터로 알려진 균일한 구조로 번역한다. 적절한 콜백 데이터 구조를 후술한다. 이후, 필터 매니저(212)는 등록된 필터 드라이버 리스트(예를 들어, 5개의 필터 드라이버 282_A-282_E가 도 2에 도시되어 있지만, 이러한 드라이버가 임의의 수 로서 존재하여도 됨)를 확인하고, 각 필터 드라이버에 대하여, 그 I/O용으로 등록된 디스패치를 호출하여도 된다. 명백하게, 본 발명의 모델에서, 필터는, IRP를 수신 및/또는 처리하지 않지만, I/O 요구로 무엇을 할 것인지에 대하여 필터 매니저(212)에게 지시한다.

도 2에도 도시되어 있듯이, 레거시 필터 드라이버(210)는 이 실시예에서 이 드라이버를 스택(210)의 최상위에 배치함으로써 지원되어도 된다. 그러나, 그 드라이버를 다른 스택 구성 요소에 대하여 부분적으로 다른 순서로 배치할 수 있다는 것을 주목하길 바란다. 예를 들어, 레거시 필터 드라이버는 콜백이 아닌 IRP를 다루도록 되기 때문에, 특별한 관리 코드가 그러한 레거시 필터와 밀접한 관계를 갖게 되어(surround) 콜백 데이터로부터 IRP를 생성하여 레거시 필터에 전달하고 (수정되었을 수도 있는) IRP를 레거시 필터로부터 수신하여 다시 상태 응답으로 변환하여도 된다. 이러한 방식으로, 레거시 필터는 콜백 모델 내에 삽입되고 분리될 수 있다. 하여간, 레거시 필터는 여전히 새로운 모델에서 사용되어도 된다.

도 2에 도시한 예를 요약하면, 파일 시스템 필터 매니저(212)는, 새로운 모델에 이용되며, 자신이 레거시 필터 드라이버인 것처럼 필터 드라이버 스택(208) 내에 배치되고, 이에 따라 IRP를 수신 및 처리할 수 있다. 이에 의해 필터 매니저는 기존의 I/O 시스템에서 간단하게 작업할 수 있지만, IRP 데이터 구조가 아닌 다른 구조에서, 갱신된 I/O 매니저가 I/O 데이터를 필터 매니저에 전달하는 등가 모델(예를 들어, 상위 레거시 필터가 없는 모델)이 제공될 수 있다는 것을 주목하길 바란다. 예를 들어, I/O 매니저가 IRP를 생성할 때, 필터 드라이버는 그 IRP로부 터 콜백 데이터 구조를 생성하고, 따라서 I/O 매니저가 콜백 데이터 구조를 직접 생성하는 것이 보다 효율적일 것이다. IRP가 아닌 다른 것이 이미 기존의 패스트 I/O, 메모리 매니저 콜백 등을 위한 시스템에 제공되어 있으며, 이들은 보다 빠른 성능을 위해 판독/기록/장치 I/O 제어와 같은 공통되는 일부 I/O 작업에 대하여 패킷이 아닌 콜백에 기초하고 있다는 것을 주목하길 바란다. 또한, 기존의 시스템에서 패스트 I/O는 여전히 스택을 통해 전달되고(즉, 연쇄되고), 이에 따라 본 발명의 콜백에 기초한 모델과 다르다는 것을 주목하길 바란다. 설명이 간략하도록, 본 발명은 특별히 다른 사항을 언급할 때를 제외하고는 IRP를 예로 들어 설명한다.

일실시예에서, 필터 드라이버는, 전형적으로 자신의 드라이버 초기화 프로시저동안 실제로 구현될 때 필터 매니저(212)에서 등록 메카니즘으로 등록하는 오브젝트 등을 포함한다. 효율성을 위해, 필터 드라이버는 처리시에 관심 대상인 파일 시스템 요구만을 등록할 것이다. 이것을 달성하기 위해, 등록의 일부로서, 각 필터 드라이버는 자신이 관심을 갖는 I/O 요구 종류(예를 들어, 생성, 판독, 기록, 종료 등)를 필터 매니저에게 통지한다. 예를 들어, 암호화 필터 드라이버는 판독 및 기록 IRP를 등록할 수 있지만, 데이터가 암호화 또는 복호화되지 않은 것에 대해서는 등록하지 않을 수 있다. 마찬가지로, 쿼터 필터는 파일 생성 및 파일 기록에만 적용될 수 있다. 그 결과로, 필터 드라이버는 관심을 갖는 I/O만을 보기 때문에, 그 모델이 스택형 필터 모델보다 보다 효율적이다.

모델이 볼륨에 부가될 수 있도록, 본 발명의 모델은 필터 드라이버 (및 후술하는 바와 같이 볼륨 컨텍스트)의 "인스턴스" 개념을 규정한다. 보다 상세하게, 볼륨에 부가하길 원하는 필터 드라이버는, 새로운 볼륨이 장착될 때 인스턴스 설정 통지를 통해 통지받는다. 필터 드라이버가 로딩되기 전에 이미 장착한 볼륨용으로 유사한 통지가 제공된다. 그후, 필터 드라이버는 후술하는 등록을 통해 볼륨에 부가하는 것을 선택할 수 있고, 만약 선택된다면 인스턴스 오브젝트가 사용되어 그 부가의 인스턴스를 표시한다. 유사한 방식으로 필터 드라이버는, 볼륨이 장착 해제될 때, 즉, 인스턴스 해제 통지를 통해 통지받는다. 본 발명에 의해 필터 드라이버는 장착된 볼륨으로부터 동적으로 분리될 수 있다.

필터 드라이버는, "Method and System for Deterministic Ordering of Software Modules"이라는 명칭으로 출원된 미국 특허출원번호 09/768,098에 일반적으로 기재되어 있듯이, 콜백 오더에서 그 드라이버가 어디에 위치하는지를 가르키는 고도와 관련될 수 있다. 또한, 도 3에 도시되어 있듯이, 필터 드라이버는 다중시간대를 동일한 볼륨에 부가하여, 각 부가에 대한 인스턴스를 생성할 수 있다(이렇게 하더라도, 그 동일한 볼륨에 대한 각 인스턴스는 순서 번호 또는 일부 오버라이드 메카니즘에 의해 반드시 서로 다른 고도에 위치한다).

도 3은 다중 인스턴스를 갖는 필터의 일예를 도시한다. 도 3에서, 필터 A, 예를 들어 "filesystem activiy monitoring" 필터는 파일 I/O를 감시하고, 2개의 인스턴스, 즉 필터 A 및 필터 A'를 갖는다. 이러한 방식으로, 파일 액티비티 모니터링 제품은, (필터 A를 통해) 중간(예를 들어, 안티바이러스) 필터 B내로 입력되는 I/O를 관측할 수 있을 뿐만 아니라, I/O이 파일 시스템으로 향하는 도중에 (필터 A'를 통해) 결국 그 중간 필터를 통과하는 I/O를 관측할 수 있다. 예를 들어, 파일 액티비티 모니터링 제품은, 후술하는 바와 같이 필터 A 및 필터 A'가 메시지를 통해 보고하는 사용자 모드 프로그램(별도로 도시하지 않음)을 포함하여도 된다.

따라서, 퍼-볼륨 필터 드라이버 인스턴스는, 각 인스턴스가 그 볼륨용으로 어디에 위치하고 있는지를 결정하는 고도와 관련될 수 있다. 고도는, 미국 특허출원번호 09/768,098에 기재된 바와 같이 소정의 필터 인스턴스로 미리 정해질 수 있으며, 그리고/또는 (후술하는) 플래그 메카니즘 등을 이용하여 필터를 위한 적절한 고도를 유도해낼 수 있다. 예를 들어, 안티바이러스 필터는, 데이터를 암호화하기 전에 있는 그대로 보기 때문에, 암호화 필터 및 베이스 파일 시스템 간에 부가되어서는 안된다. 플래그는 필터가 데이터를 검사하는지(예를 들어, 안티바이러스 필터), 데이터를 수정하는지(예를 들어, 암호화 필터) 등의 여부를 가르킬 수 있고, 이에 따라 고도가 유도될 수 있다. 이러한 방식으로, 콜백 오더는 드라이버가 로딩되는 순서에 기초하지 않으며 소정의 일부 논리에 기초한다.

본 발명의 일 양태에 따라, 필터 드라이버는 2가지 종류의 콜백, 즉 프리-콜백 및 포스트-콜백을 등록한다. 프리-콜백은 파일 시스템으로 향하는 I/O의 진행 경로 상에서 호출되는 반면, 포스트-콜백은 그 I/O의 완료동안 파일 시스템으로부터 다시 I/O 매니저에게로 향하는 진행 경로 상에서 호출된다.

효율성을 위해, 어느 필터 드라이버가 어떤 종류의 콜백을 등록하였는지를 추적하고 이에 따라 I/O(즉, IRP)가 수신될 때 어느 필터 드라이버가 호출하는지를 효율적으로 결정하기 위해, 필터 매니저(212)는 하나 이상의 퍼-볼륨 데이터 구조 를 유지한다. 예를 들어, 도 4에 도시한 바와 같이, 필터 인스턴스가 (예를 들어, 함수를 호출함으로써) 필터 매니저(212)내의 등록 메카니즘(402)에서 등록을 수행할 때, 이 등록 메카니즘은 순서화 메카니즘(404)을 통해 프리-콜백 오더내에서 필터 인스턴스가 어디에 속하는지를 결정한다. 순서화 메카니즘(404)은 고도의 단순 비교에 기초할 수 있고, 또는 필터 인스턴스가 어디에 맞는 것인지를 결정하기 위한 플래그를 평가하는 논리를 포함할 수 있다. 어떠한 경우이든, 퍼-볼륨 콜백 노드는, 그 내부에 등록 정보를 갖는 상태에서 유지된다.

후술하는 바와 같이, 등록시 필터 매니저에 전송되는 정보의 일부는 필터 인스턴스가 프리-콜백을 원하는 파일 시스템 요구의 리스트(예를 들어, 어레이)를 포함한다. 이 정보를 이용하여 퍼-볼륨 순서화 리스트 408(예를 들어, 볼륨 c:) 또는 410(예를 들어, 볼륨 d:)등을 구성하고, 이에 의해 필터 매니저(212)내의 콜백 메카니즘(412)은 각 인스턴스를 호출하기 위한 순서를 효율적으로 결정할 수 있다. 예를 들어, 도 4에 도시한 바와 같이, 볼륨 c:에 대한 파일 판독 요구가 수신되면, (IRP의 IRP 메이저 코드에 의해 인덱싱될 때) 판독에 관련된 필터 인스턴스를 빠르게 얻을 수 있으며, 즉, 도 4의 예에서 나타낸 바와 같이 필터 인스턴스 A, 필터 인스턴스 B, 및 필터 인스턴스 A'가 프리-콜백 오더로 될 것이다. 이것은 매우 효율적이며 또한 동적 등록을 용이하게 한다는 것, 즉, 새로운 필터가 등록하는 어떠한 순간에라도, 등록 메카니즘은 리스트를 적절히 재구성할 수 있다는 것을 주목하길 바란다.

이러한 방식으로, 프리-콜백 오더는 I/O 요구의 종류에 따라 결정되며, 후술 하는 바와 같이, 각 필터 인스턴스에 의해 리턴되는 상태가, 콜백을 수신하는 실제 필터 인스턴스에 영향을 가할 수도 있으며, 즉, 필터가 콜백을 적절히 수신하지 못할 수 있다. 포스트-콜백은 본질적으로 역순으로 동작하며, 후술하는 바와 같이, 프리-콜백에서 호출된 인스턴스가 리턴할 수 있는 상태값중 하나는 포스트-콜백없이 성공이며, 이 경우 필터 매니저(212)는 그 인스턴스용 포스트-콜백을 스킵할 것이다.

콜백에 응답하여 필터 인스턴스가 리턴할 수 있는 상태값에는, 일반적으로 콜백없는 성공, 콜백있는 성공, 펜딩, 동기, 완료, 및 패스트 I/O 사용불가가 있다. 일실시예에서, "FLT_PREOP_SUCCESS_NO_CALLBACK"은 계속해서 I/O 통과를 처리하고, "FLT_PREOP_SUCCESS_WITH_CALLBACK" 상태도 마찬가지이며, 이것은 그 I/O가 완료될 때 완료 콜백을 더 요구한다. 필터는 FLT_PREOP_PENDING을 더 특정화할 수 있으며, 이 상태값은 필터가 FltCompletePendedPreOperation()을 나중에 호출할 때까지 I/O를 홀드한다. FLT_PREOP_SYNCHRONIZE는 I/O가 완료되기를 기다리며, 초기 쓰레드 컨텍스트에서의 포스트-콜백을 호출한다. I/O 동기는 필터 매니저에 의해 처리된다. "펜딩" 및 "동기"는 패스트 I/O로 리턴될 수 없음을 주목하길 바란다. FLT_PREOP_COMPLETE는 성공 또는 실패 상태 코드(이것은 일반적으로 레거시 디스패치에 있어서 IoCompleteRequest에 유사함)로 I/O를 완료한다. FLT_PREOP_DISALLOW_FAST_IO는 패스트 I/O용으로만 유효하고, 일반적으로 레거시 디스패치에서 FALSE를 리턴하는 것과 등가이다.

이러한 방식으로, 관리화된 필터 드라이버 모델에 의해 필터 드라이버는 드 라이버의 프리-콜백 루틴으로부터의 리턴 상태를 통해 I/O의 수행 경로를 제어할 수 있다. 이에 의해 필터 드라이버는, 펜딩, 완료, 하위 필터로의 통과, 포스트-콜백 요구, 동기화 요구, 포스트-콜백 등의 요구를 포함하여, I/O가 처리되는 여러 방식을 요구할 수 있다.

상술하는 바와 같이, 필터 인스턴스는 포스트-콜백을 등록한다. 포스트-콜백에 응답하여, 필터 인스턴스(예를 들어, FLT_PREOP_SUCCESS_WITH_CALLBACK의 상태를 리턴한 필터 인스턴스)는 FLT_POSTOP_FINISHED_PROCESSING 상태를 리턴하여 I/O 완료를 계속하거나, FLT_POSTOP_MORE_PROCESSING_REQUIRED 상태를 리턴하여 완료를 포기하고 FltCompletePendedPostOperation() 함수를 나중에 호출함으로써 I/O를 완료할 수 있다. 필터는 리파스 핸들러를 위한 FltReissueSynchronousIo() 함수 호출을 통해 자신의 포스트 연산 처리동안 I/O를 다시 재송신할 수 있다. FLT_POSTOP_UNDO_CREATE 상태는 생성 요구를 실패함으로써 파일 오픈을 차단하려는 필터용으로 제공된다.

I/O 완료는, 필터 매니저의 프리-콜백에 있어서 필터 인스턴스에 의해 보이는 파라미터가 필터 매니저의 포스트-콜백에서와 동일함을 보장하는 방식으로 필터 매니저(212)에 의해 처리된다. 이것은, 필터가 파라미터, 버퍼 포인터 등을 자주 변경하여 많은 문제점을 야기하는 레거시 스택형 모델에 비하여 향상된 것임을 주목하길 바란다. 일반적으로, 이것은 도 5에 도시한 바와 같이 수행되며, 여기서 필터 매니저는 각 인스턴스에 대한(즉, 적어도 콜백을 수신하는 인스턴스에 대한) 완료 노드를 유지한다.

본질적으로, (자신의 상태를 통해) 콜백을 요구한 프리-콜백에서 호출된 각 인스턴스에 대하여, 필터 매니저는 각 프리-콜백 이전의 파라미터를 스냅샷한고, 그 스냅샷을 완료 노드에 저장하며, 이 완료 노드를 스택(502)상으로 푸시한다. 포스트-콜백 데이터를 관리하기 위해, 각 IRP에 대하여, 필터 매니저는, 필터 드라이버에 의해 보이지 않으며 장치 오브젝트를 포함한 정보, IRP 포인터, 완료 노드의 크기를 포함한 노드 정보, 및 대응하는 인스턴스 등을 추적하는 IRPCTRL 헤더(504)를 유지한다. 그후, 포스트-콜백동안, 필터 매니저는 워크백하고, 각 완료 노드를 스택(504)에서 팝핑하여 그 완료 노드를 인스턴스용 콜백 데이터(506)내에 두며, 이에 따라 파라미터를 저장하게 된다. 스택은, 필터 인스턴스가 순서에서 프리 콜되기 전에 동적으로 등록한다면, 추가된 완료 노드를 갖는 다른 스택으로 복사될 수 있음을 주목하길 바라며, 소정의 IRP에 대하여 프리 콜링 순서에서 프리 콜링이 이미 그 스택을 전달한 후에 필터 인스턴스가 등록되었다면, 그 인스턴스는 콜백되지 않을 것이다.

효율성을 위해, 스택은, 필터 인스턴스가 콜백을 수신할 때 그리고 필터 인스턴스가 콜백 데이터를 변경할 때에만, 완료 노드를 스택 상으로 푸시할 필요가 있으며, 그렇지 않은 경우에 푸시하게 되면 그 완료 노그를 재사용할 수 없기 때문이다. 필터 인스턴스는 데이터를 수정할 때 더티(dirty) 파라미터 플래그를 설정하는 것을 담당한다. 필터 인스턴스가 더티 파라미터 플래그를 설정하지 않는다면, 데이터 수정이 폐기될 것이며 그 변경된 데이터가 스냅샷되지 않을 것이며, 이에 따라 어떠한 변경도 다른 드라이버에 의해 보이지 않을 것임을 주목하길 바란 다.

도 2를 다시 참조하면, 최종 포스트-콜백이 행해진 후, 필터 매니저(212)는 그 콜백 데이터를 IRP로 재변환(배열(marshals))하여 I/O 매니저(206)를 향하여 임의의 상위 레거시 필터(210)를 통해 그 IRP를 스택 위에 리턴한다. 상기한 바와 같이, 이 관리화된 필터 모델에 의해, 레거시 모델의 많은 단점이 제거되거나 상당히 감소하게 된다.

상기한 기능에 더하여, 필터 매니저는, 필터가 공통적으로 필요로 하는 기능을 제공하는 리치 API 세트를 더 제공한다. 예를 들어, 일부 필터는 자신의 고유한 I/O를 수행할 필요가 있으며, 예를 들어, 안티바이러스 필터는 파일이 오픈되기 전에 그 파일을 판독하길 원할 수 있다. 필터 드라이버가 자신의 고유한 I/O 연산을 개시하길 원할 때, 이 필터 드라이버는 FltAllocateCallbackData()를 호출한다. 이 함수는 FLT_CALLBACK_DATA 구조를 할당하고 리턴하며, 이후 필터는 그 구조를 임의의 상대 필드로 위치시킨다(populate). FltAllocateCallbackData는 본질적으로 레거시 시스템에서 IoAllocateIrp()를 호출하기 위한 교체임을 주목하길 바란다. 필터가 임의의 나머지 필터, 레거시 필터, 및 베이스 파일 시스템 상에 I/O 요구를 전송할 준비가 되었을 때, 이 필터는 FltPerformSynchronousIo() 또는 (IoCallDriver()에 유사한) FltPerformAsynchronousIo()를 호출한다. 기본적으로, 필터-개시된 I/O는 소정의 볼륨용으로 그 다음 부가된 필터에 전송되며, 그 I/O를 개시한 필터 위에 부가된 임의의 필터를 통과하게 된다. 그러나, 계층적 저장 관리(HSM) 필터가 그 I/O를 개시할 필요가 있을 때, 이 I/O를 시스템 내의 임의의 장 치에 전송할 수 있다.

다른 예로서, 필터는 때때로 파일을 생성할 필요가 있으며, FltCreateFile() 함수는 I/O를 개시하기 위한 시작점으로서 제공된다. 이 함수는, 파일 핸들을 취하는 기존의 운영 시스템 API와 함께 사용될 수 있는 핸들을 리턴하고, 파일을 다른 인스턴스 상에서 생성할 수 있게 한다. 이 함수는 공유-액세스 오버라이드를 지원한다. 또한, 필터 매니저는, 순환적 콜백을 회피하는 동적으로 삽입되는 필터를 포함하여 요구하는 필터 아래의 필터에 의해서만 임의의 콜백이 보이는 것을 보장한다. 이것을 달성하기 위해, 필터 매니저는 인스턴스 힌트로 파일을 생성하고, 이 힌트를 이용하여 요구하는 필터를 식별한다. 마운트 포인트 오픈이 콜백 스택의 최상위로 갈 필요가 있을 때는 예외임을 주목하길 바란다.

FltReadFile()로 인해, I/O 완료시에 송신될(issued) 필터 공급된 콜백을 갖는 동기 및 비동기 I/O가 가능해진다. FltWriteFile(), FltSetInformationFile() 등은 유사한 시맨틱을 갖는다. I/O 완료 콜백을 허용하는 FltPerformSynchrounousIo(), 또는 FltPerformAsynchrounousIo()를 포함하여, FltAllocateCallbackData()로 인해 I/O는 개별화될 수 있다.

컨텍스트 관리는, 필터가 컨텍스트 구조를 각 스트림 핸들, 인스턴스, 및 볼륨과 종종 관련시킬 때, 필터 매니저-제공된 API가 매우 이로운 또다른 예이다. 예를 들어, 필터는 컨텍스트를 이용하여 퍼 핸들/퍼 스트림/퍼 파일/퍼-볼륨/필터가 I/O를 인터럽트할 때 참조되는 퍼 인스턴스 정보를 저장한다. 필터가 엔티티 상에 설정한 임의의 컨텍스트 또는 복수의 컨텍스트는, 그 필터가 요구할 때 예를 들어 API를 통해 그 필터에 전달될 것이다. 이 컨텍스트 수명은 필터 매니저(212)에 의해 관리되며, 필터는 삭제되는 (스트림/파일/인스턴스/볼륨과 같은) 적절한 오브젝트로 인해 그 컨텍스트가 삭제될 때 콜백될 것이다.

본 발명의 또다른 양태에 따르면, 필터 매니저(212)는 적절한 오브젝트에서의 각 필터를 위한, 즉, 스트림 핸들, 스트림 파일, 인스턴스 또는 볼륨을 위한 컨텍스트 데이터(예를 들어, 포인터 등)를 저장하기 위해 효율적인 컨텍스트 지원을 제공한다. 이것을 달성하기 위해, 본 발명은, 컨텍스트를 엔티티에 리턴하는 한 세트의 API를 통한 컨텍스트 지원을 제공하고, 퍼 필터 컨텍스트와 그 엔티티와의 관련성을 간략화한다. 컨텍스트는 어느 때라고 설정될 수 있으며 그리고/또는 리셋될 수 있다. 또한, 본 발명은 인스턴스용 통지를 설정하는 한 세트의 콜백을 통한 인스턴스용 통지 지원을 제공한다.

엔티티 종류에는, 인스턴스, 볼륨 (로컬 디스크 볼륨, 또는 원격 네트워크 공유), (파일당 다중 스트림을 지원하는 파일 시스템용) 스트림, 스트림 핸들 (퍼 파일 오브젝트), 및 파일(예를 들어, 하나의 파일의 모든 스트림)이 포함된다. 인스턴스를 예로 들면, 상기한 바와 같이, 필터가 볼륨에 부가될 때, 인스턴스가 생성되고, 또한 상기한 바와 같이, 소정의 볼륨에 대하여 소정의 필터의 하나 이상의 인스턴스, 즉, 동일한 볼륨 상의 다른 필터의 아래 및 위에 부가되는 인스턴스가 존재할 수 있다. 각 인스턴스는 자신의 인스턴스를 위한 개인 로그를 포인팅하는데 관련된 컨텍스트를 가질 수 있다. 볼륨 컨텍스트는 필터 인스턴스 간에 공유될 수 있다.

컨텍스트가 오브젝트와 연관성을 갖도록, 필터는 컨텍스트의 종류(스트림 핸들, 스트림, 파일, 인스턴스 또는 볼륨)를 특정하는 FltAllocateContext(), 그 컨텍스트 크기, 및 그 컨텍스트가 페이지드(paged) 또는 넌페이지드 풀 메모리로부터 할당되어야 하는지 여부를 호출한다. 일단 컨텍스트가 할당되어 초기화되면, 필터는 적절한 루틴, 즉 FltSetStreamHandleContext(), FltSetStreamContext(), FltSetFileContext(), FltsetInstanceContext(), 또는 FltSetVolumeContext()를 호출함으로써 그 컨텍스트를 오브젝트와 관련시킨다.

도 6에 도시한 바와 같이, 파일, 스트림, 및 스트림 핸들과 관련된 필터 인스턴스를 효율적으로 참조하기 위해, 필터 매니저(212)는 파일 오브젝트와 관련된 데이터 구조에 트리(즉, 스플레이 트리)를 더한다. 보다 상세하게, 운영 시스템은 임의의 컨텍스트를 스트림에 더하는 것을 용이하게 하며, 필터 매니저(212)는 이러한 메카니즘을 이용하여 스트림 제어 리스트(608) 및 트리(610)를 FSRTL_ADVANCED_FCB_HEADER(612)에 더하며, 이것은 본질적으로 컨텍스트(616)를 통해 파일 오브젝트(614)에 의해 포인팅된다. 트리(610)에서 각 노드는 이 스트림에 관련된 컨텍스트를 갖는 필터 인스턴스를 나타낸다. 별도로 도시되어 있지 않지만, 페이지드 풀 메모리용 트리 하나 그리고 넌페이지드풀 메모리용 트리 하나처럼, 필요할 수 있는 여러 종류의 액세스에 대하여 필터 인스턴스에 의해 특정화될 때, 병렬 트리가 존재하여도 된다.

소정의 스트림 핸들을 위해, 트리에서의 각 노드는, 파일 오브젝트를 하나의 키로서 그리고 인스턴스를 다른 키로서 포함하는 키에 의해 액세스된다. 스트림을 위해, 파일 오브젝트 키는 NULL임을 주목하길 바란다. 도 7에 도시한 바와 같이, 필터 매니저(212)내의 (또는 필터 매니저(212)와 관련된) 컨텍스트 메카니즘(412)으로의 함수 호출에서의 데이터를 통해 이러한 키가 제공될 때, 트리(610)에서의 적절한 노드는 필터 드라이버 인스턴스(702)용으로 빠르게 위치지정될 수 있고, 적절한 컨텍스트(704)(예를 들어, 컨텍스트 포인터의 형태임)는 요구하는 필터 드라이버 인스턴스(702)에 리턴된다. 일반적으로 소정의 구성에서 그렇게 많은 필터 인스턴스가 존재하지 않기 때문에 부분적으로는 그 이동(traversal)이 빠르다.

일실시예에서, 필터는 인스턴스용 통지를 수신할 수 있다.

특정 인스턴스를 위한 컨텍스트가 필요하면, 이 콜백에서 컨텍스트를 설정할 수 있다. 컨텍스트가 PVOID 이며, 시스템은 그 컨텍스트를 완전히 불명료한 것으로 볼 것이며, 이에 따라 필터는 그 컨텍스트를 이용하여 플래그 필드, 카운터, 포인터, 또는 필요한 다른 임의의 것을 저장할 수 있다. 필터가 자신의 인스턴스 콜백을 성공적으로 초기화할 수 있고 이 볼륨 상의 액티비티를 감시하려 한다면, STATUS_SUCCESS를 리턴해야 한다. 필터가 이 인스턴스가 볼륨 상에서 생성되는 것을 원하지 않는다면, STATUS_FLT_DO_NOT_ATTACH를 리턴해야한다. 새로운 연산이 볼륨으로 올 수 있기 때문에, 인스턴스용 통지 클린업 콜백이 제공되어 인스턴스 테어다운(teardown)를 적절히 동기화하며, 이 콜백은 InstanceQueryTeardown, InstanceTeardownStart, 및 InstanceTeardownComplete을 포함한다.

일부 엔티티용 컨텍스트 구조를 제공하는 필터는 자신의 대응하는 ContextCleanupCallback을 호출할 것이다. 다시 말하면, 메모리 풀이 누설되는 것을 피하기 위해, 필터는 어느 컨텍스트를 할당하였는지를 추적할 필요가 없으며, 언제 클린업이 발생해야 하는지를 시스템이 추적하기 때문이다. 컨텍스트가 사용되지 않는 상태로 되어야 할 때, 시스템은 필터의 ContextCleanupCallback을 호출한다. 이 콜백동안, 필터는 컨텍스트의 컨텐츠를 언이니셜라이즈(uninitialize)하는 것을 담당하며, 리턴때 시스템은 필터의 초기 FltAllocateContext() 호에 의해 할당된 메모리를 사용가능하게 할 것이다. 클린업은 성공이라 가정되며, 이에 따라 리턴값이 존재할 필요가 없다. 또한, 시스템은, 풀이 사용가능해지는 것이 안전하게 행해질 수 있을 정도로 낮은 IRQL에서 컨텍스트 클린업 루틴이 호출되는 것을 보장한다.

인스턴스 컨텍스트는 필터가 볼륨으로부터 분리될 때 클린업된다. 볼륨 컨텍스트는, 그 볼륨이 장착 해제된 후, 그리고 그 볼륨용의 모드 파일, 스트림, 및 스트림 핸들이 클린업된 후, 클린업된다. 메모리 매니저, 캐시 매니저, 및 파일 시스템 실시예의 세부 사항으로 인해, 볼륨 컨텍스트는 그 볼륨이 장착 해제된 후 비교적 오랜 시간동안 클린업되지 않을 수 있다.

파일 컨텍스트는 파일 시스템이 파일과 관련된 메모리를 사용가능하게 할 때 클린업되고, 이것은 다중 스트림 파일 시스템에서 그 파일에 대한 최종 스트림용 최종 스트림 핸들이 사용가능하게 된 후 클린업될 것이다. 운영 시스템의 메모리 매니저 및 캐시 매니저는 여전히 그 파일 내의 하나 이상의 스트림을 참조하기 때문에, 스트림에 대한 최종 사용자 핸들이 종료된 후 파일 컨텍스트는 비교적 오랜 시간동안 클린업되지 않을 수 있음을 주목하길 바란다. 유사한 방식으로, 스트림 컨텍스트는, 파일 시스템이 스트림과 관련된 메모리를 사용가능하게 할 때 클린업되고, 이것은 그 스트림용 최종 스트림 핸들이 사용가능하게 된후 클린업될 것이다. 또한, 운영 시스템의 메모리 매니저 및 캐시 매니저가 여전히 파일 내의 하나 이상의 스트림을 참조하기 때문에, 스트림에 대한 최종 사용자 핸들이 종료된 후 파일 컨텍스트는 비교적 오랜 시간동안 클린업되지 않을 수 있다.

스트림 핸들 컨텍스트는, 스트림 핸들에 대한 최종 참조가 끝날 때 클린업된다. 이것은 사용자 핸들이 해제되거나 최종 메모리 매니저 또는 캐시 매니저 참조가 해제됨으로써 발생할 수 있다.

컨텍스트는, 오브젝트가 현재 컨텍스트를 갖기 않는다면 그 오브젝트용으로 설정될 수 있고, 또는 변경될 수 있다. 필터는, FltDeleteContext(), FltdeleteVolumeContext(), FltDeleteInstanceContext(), FltDeleteFileContext(), FltDeleteStreamContext(), 및 FltDeleteStreamHandleContext() 루틴들중 하나를 적절히 이용하여 컨텍스트를 클리어할 수 있다.

흔히, 필터는 엔티티에 관심을 갖고 있는지를 결정하기 위해 엔티티에 대한 기본적인 몇 개의 정보를 원한다. 볼륨을 위해, 이것은, 그 볼륨이 로컬 또는 원격인지간에, 이것이 소거가능한 매체 등 상에 위치하는지간에, 파일 시스템일 수 있다. 파일을 위해, 이것은 파일 이름, 타임스탬프, 크기, 확장자 등을 포함하여도 된다. 시스템은 이 정보를 쉽게 검색하기 위해 함수(예를 들어, FltGetFileInformation(), FltGetVolumeInformation())를 노출해도 된다. 또한, 필터는 FltTagFile()을 호출하여 파일 상에 리파스 포인트를 설정해도 된다.

본 발명의 아키텍쳐에 의해 제공되는 또다른 세트의 API는, 필터 인스턴스와 사용자 모드 코드 간의 통신을 용이하게 하는 것이다. 보다 상세하게, 많은 필터는 전형적으로 제품의 관리 구성 요소인 사용자 모드 서비스 카운터파트를 갖는다. 본 발명의 아키텍쳐는, 커널 개시 통신 뿐만 아니라 사용자 모드 개시 통신 모두를 사용하는 이러한 제품을 위한 API를 제공할 수 있다.

예를 들어, 사용자 모드 구성 요소와 통신하는 필터를 위해, 그러한 사용자 모드 어플리케이션용으로 라이브러리가 이용가능하다. 라이브러리는,

필터를 로드 및 언로드하는 루틴, 필터를 볼륨에 부가 및 분리하는 루틴, 통신 채널을 사용자 모드로부터 필터에 개방하고 필터로부터 데이터를 송수신하는 루틴, 및 시스템의 현재 상태 상의 정보를 위해 시스템을 쿼리하는 루틴을 포함하는 루틴을 노출시킨다. 예를 들어, 사용자 모드 프로그램은 어느 필터가 현재 로드되어 있는지, 어떤 인스턴스가 소정의 볼륨 상에 또는 소정의 필터를 위해 존재하는지 등을 쿼리할 수 있다. 필터-사용자 통신 API는, 필터가 자신의 고유한 개인 통신을 수행하기 위해 사용하는 것이 때문에, 필터/인스턴스 열거, 필터 로딩/언로딩 등을 가능하게 하는 관리 API와 다르다는 것을 주목하길 바란다.

요약하면, 새로운 필터 모델은, 볼륨에 대한 동적 로드/언로드, 동적 부가/ 분리, 유연성있는 순서화, 및 대부분의 필터가 공통적으로 필요로 하는 API의 리치 세트에 대한 액세스가 가능한 파일 시스템 필터의 안정적이며 효율적인 기록 방식을 제공한다. 이하, Windows

NT/2000/XP 운영 시스템에 기초한 일실시예를 상세하게 설명한다.

일실시예

다음에 따르는 설명은, 제1 매니저와의 등록을 포함하여 함수 호출을 통해 수행되는 필터 개시 연산중 일부에 관한 것이다.

필터는 관심을 갖는 I/O에 대한 콜백을 선언한다.

필터는 등록 구조를 선언한다.

필터는 필터 매니저에 등록한다.

필터는 프리-콜백을 갖는다.

이 실시예에서, 파일 시스템 필터 드라이버는 NT 커널 모드 드라이버를 포함하며, DriveEntry()라 불리는 함수를 노출시킬 필요가 있으며, 이 함수는 드라이버가 로드될 때 가장 먼저 호출되는 함수이다. 함수가 로딩될 때, 필터는 그 함수를 호출하여 지명된 FltRegisterFilter()를 자신의 DriveEntry()에 등록한다. FltRegisterFilter()는 FLT_REGISTRATION 구조를 파라미터로서 취하고, 이 구조는, (여러 가지 중에서) 인스턴스 셋업 및 테어다운 콜백, 컨텍스트 콜백 함수 포인터의 리스트, 및 파일 시스템 연산용 콜백 포인터의 리스트를 포함한다. 필터가 비교적 적은 수의 연산으로 후크(hook)되길 원하며 행여 존재한다면 오브젝트용 컨텍스트를 설정하는데에만 관심을 갖는 많은 경우에, 이 리스트는 매우 짧을 수 있음을 주목하길 바란다.

다른 실시예에서, 고도가 유도되는 하나 이상의 필터 속성 플래그를 필터가 설정하는 플래그 필드가 존재하여도 된다. 예를 들어, 플래그는, 베이스 파일 시 스템으로 전달되는 또는 베이스 파일 시스템으로부터 전달되는 데이터가 필터에 의해 수정됨을 암호화 또는 압축 필터가 시스템에게 통지하는 것처럼, 데이터를 수정하는 필터에 의해 설정되어도 된다. 이 실시예에서, 사용자의 데이터를 다중 스트림으로 분할하는 임의의 필터도 이 플래그를 설정해야 한다. 또한, 필터는 예를 들어, 평문이며 압축되지 않은 데이터를 보길 원하는 바이러스 필터가 이 플래그를 설정하듯이, 필터가 데이터를 검사하는 것을 가르키기 위해 플래그를 설정할 수 있다. 또한, 플래그는, (타임스탬프 및 날짜와 같은) 표준 정보를 수정하는 필터, (예를 들어, 파일 날짜에 기초하여 파일 상에서 다른 연산을 수행하기 위해) 표준 정보를 검사하는 필터, 생성을 다른 이름의 파일/스트림으로 경로설정(redirect)하는 필터(예를 들어, 심볼 링크/SIS형 필터), 및 (.EXE 및 .DOC 파일을 스캔하는 바이러스 필터와 같이) 파일 이름에 의존하는 필터용으로 이용가능하다.

상기한 바와 같이, 이러한 플래그를 이용하여 시스템이 필터를 볼륨에 정확한 순서로 부가하는 것을 도울 수 있다. 예를 들어, 안티바이러스 필터는, 데이터가 암호화되기 전에 그 데이터를 있는 그대로 볼 필요가 있기 때문에 암호화 필터와 베이스 파일 시스템 사이에 부가되지 않아야 한다. 이것을 방지하기 위해, 모델은, 필터가 데이터를 수정하는 것을 가르키는 것으로 설정된 플래그를 필터에 부가하도록 설정된 데이터 플래그를 필터가 검사함을 가르키는 플래그를 필터가 갖도록 허용하지 않는다. 또한, 이러한 플래그의 일부 조합을 이용하여 필터가 부가되는 것을 방지할 수 있으며, 예를 들어, 각 필터가 데이터를 검사 및 수정하는 것을 가르키는 플래그를 2개의 필터가 설정하면, 이 2개 필터가 안전하게 동일한 볼륨에 부가될 수 있는 순서가 존재하지 않는다.

다음에 따르는 것은 파일 시스템 필터 드라이버의 종류를 위한 하나의 논리 순서화를 나타낸다.

상기한 바와 같이, 콜백 데이터는, 연산을 설명하는 필요한 정보를 필터 드라이버에게 나타내기 위한, IRP에 다소 유사한, I/O 리프리젠테이션의 유닛이다. 콜백 데이터는 파일 시스템 필터의 사용에 특정화된 파라미터를 포함하며, 패스트 I/O, IRP, 및 FsFilter 호를 위해 존재한다. 변경가능한 파라미터 섹션은 드라이버에 의해 수정될 수 있으며(즉, 더티(dirty)될 수 있음), 파라미터 섹션은 후술하는 완료 노드 스택 팝핑 연산을 통해 필터 단위로 필터 매니저에 의해 실행을 받게 된다.

다음은 콜백 데이터 구조의 일예이다.

다음은 I/O 파라미터 블록의 일예이다.

전 연산(pre-operation) 콜백은 동일한 시그너쳐를 갖는다.

상기한 바와 같이, 전 연산 콜백은 FLT_PREOP_CALLBACK_STATUS를 위한 다음 의 상태들 (및 다른 것들) 중 하나를 리턴할 수 있다.

후 연산 콜백은 동일한 시그너쳐를 갖는다.

플래그는 아래와 같은 것을 포함할 수 있다.

FLT_POSTOP_CALLBACK_STATUS:

필터는 전 연산 콜백마다 완료 콜백을 수신할 것이다. 예를 들어, 메모리가 프리-콜백에서 할당된다면, 완료 콜백에서 그 메모리를 사용가능하게 하는 기회가 필터에게 주어질 수 있으며, 완료 콜백은 1번 이상 그 메모리를 사용가능하게 하도록 필터를 시동하기 위해 1번 이상 호출되지 않을 것이다.

IRP_MJ_CREATE에서부터 IRP_MJ_PNP까지의 기존의 IRP_MJ_codes를 포함하여 프리-콜백 및 포스트-콜백용 연산이 제공될 수 있으며, 이 IRP_MJ_codes는 IRP 등가가 없는 패스트 I/O 연산, 및 FS 필터 연산을 나타내기 위해 생성된 것이다. 미래의 운영 시스템 버전이 새로운 IRP_MJ_codes를 추가한다면, 기존의 필터는 영향을 받지 않을 것이고, 그 필터가 컴파일되었을 때 존재하지 않은 IRP_MJ_routines을 위한 어떠한 콜백도 수신하지 않을 것이다. 필터가 운영 시스템이 인식하지 못하는 IRP_MJ_code로 등록하면, FltRegisterFilter()는 특별한 성공 상태를 리턴할 것이며, 그 버전에서 존재하는 함수용 콜백만을 호출할 것이다. 하나 이상의 콜백이 제공되지 않을 때 필터가 계속하여 실행되는 것을 원하지 않는다면, 그 필터는 FltUnregisterFilter()를 호출할 수 있다.

IPR_MJ_READ 및 IRP_MJ_WRITE용 콜백이 IRP에 기초한 I/O 및 패스트 I/O를 위해 시동될 것임을 주목하길 바란다. IRP_MJ_CREATE용 프리 콜아웃에는 파일 또는 스트림용 컨텍스트가 전달되지 않을 것이며, (행여 존재한다면) 어떤 파일 또는 스트림이 생성될 예정인지를 전 생성(pre-create) 시간에서 결정하지 못하기 때문이다. IRP_MJ_CLOSE용 포스트-콜아웃에는 어떠한 컨텍스트도 전달되지 않을 것이며, 포스트 클로즈 루틴이 호출되기 전에 관련된 시스템 내부 구조가 사용가능하게 되기 때문이다. IRP_MJ_CLEANUP 및 IRP_MJ_CLOSE용 프리-콜백은 계속되어야 하며 FLT_PREOP_SUCCESS_WITH_CALLBACK 또는 FLT_PREOP_SUCCESS_NO_CALLBACK을 리턴해야 한다.

후 연산 콜백은 DPC 레벨에서 호출될 가능성이 있으며, 이에 따라 리소스 또는 뮤텍스(mutexe)를 대기하지 않아야 하며, 또한 대기하는 어떠한 함수도 호출하지 않아야 한다. FltSetFileContext()와 같은 루틴은 리소스를 획득하며 따라서 후 연산 콜백으로부터 호출되지 않을 수도 있다는 것을 주목하길 바란다.

상기한 바와 같이, 포스트-콜백은 FLT_POSTOP_STATUS_SUCCESS 또는 FLT_POSTOP_MORE_PROCESSING_REQUIRED를 리턴한다. 포스트-콜백은 IoStatus에서 에러 코드를 설정함으로써 실패할 수 있고, 일반적으로 발생해버린 어떠한 것이든 그것은 필터가 담당해야 한다는 것이 규칙이다.

필터 인스턴스를 동적으로 등록하는 것에 더하여, 필터 인스턴스는 동적으로 분리될 수 있으며, 이에 따라 그러한 필터 인스턴스는 그 볼륨 상에서 임의의 연산을 위해 더 이상 호출되지 않을 것이다. 본질적으로 필터를 언로드한다는 것은, 필터의 코드가 더 이상 메모리에 있지 않다는 것을 의미한다. 이것은 시스템 셧다 운 시간에서 그리고 시스템을 셧다운하지 않고 새로운 필터 버전이 설치될 때 가장 흔하게 행해질 것이다.

필터 인스턴스는 현재 I/O가 존재할 때에도 분리될 수 있음을 주목하길 바란다. 이 경우, 플래그 FLTFL_POST_OPERATION_DRAINING 세트를 갖는 임의의 현재 I/O 연산을 위해 필터의 완료 루틴 또는 복수의 루틴이 호출될 것이다. 필터는 그러한 I/O 연산이 실제로 완료될 때 완료 콜백을 수신하지 않을 것이다. 필터 인스턴스가 분리될 때, 시스템은, 그 인스턴스와 관련된, 파일, 스트림 및 스트림 파일 오브젝트용 현재의 컨텍스트를 위해, 루틴을 호출하여 필터의 컨텍스트를 사용가능하게 할 것이다.

본 발명은 다양하게 수정되거나 다른 구성으로 대체될 수 있으며, 일부 실시예가 도면에 도시되어 있으며 상세히 설명되었다. 그러나, 설명한 특정 형태로 본 발명을 제한하는 것이 아니며, 본 발명의 사상 및 범위로부터 벗어나지 않고 모든 수정, 대체 구성, 및 등가물을 포함한다.

상기한 바에 의해 알 수 있듯이, I/O 핸들링 요구사항의 상당 부분을 다루는 관리화된 필터 드라이버 아키텍쳐가 제공되고, 이에 따라 보다 간단하고 안정적인 필터 드라이버를 제공하게 된다.

드라이버는 관심을 갖는 I/O만을 선택적으로 등록할 수 있어, 효율성이 개선된다. 동적 로드 및 언로드, 부가 및 분리를 달성한다. 다른 이점으로는, 다중 스트림 용량을 갖는 파일 시스템 상에서의 관리를 포함하여 컨텍스트 관리도 있다. 따라서, 본 발명의 방법 및 시스템은 최신 컴퓨팅에 필요한 상당한 이점을 제공한다.

Claims

컴퓨팅 환경에서,

파일 시스템으로 향하는 상기 파일 시스템의 I/O 요구를 수신하는 단계;

상기 I/O 요구에 대응하는 데이터를 제1 필터 드라이버에 전달하는 것을 포함하여, 프리-콜백 오더에 기초하여 프리-콜백으로 상기 제1 필터 드라이버를 호출하는 단계;

상기 I/O 요구에 대응하는 데이터를 최종 필터 드라이버에 전달하는 것을 포함하여, 상기 프리-콜백 오더에 기초하여 최종 필터 드라이버를 호출하는 것을 비롯하여, 다른 프리-콜백으로 적어도 하나의 다른 필터 드라이버를 호출하는 단계; 및

상기 필터 드라이버중 적어도 하나에 의해 처리된 상기 I/O 요구에 대응하는 데이터를 포함하는 상기 파일 시스템 I/O 요구를, 상기 파일 시스템에 전달하는 단계

를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 파일 시스템 I/O 요구의 데이터를, 상기 제1 필터 드라이버에 전달하기 위한 콜백 데이터로 변환하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제2항에 있어서,

상기 최종 필터 드라이버로부터 수신한 콜백 데이터를, 상기 파일 시스템에 전달되는 상기 파일 시스템 I/O 요구로 재변환하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 I/O 요구에 대응하는 데이터를 상기 제1 필터 드라이버에 전달하는 상기 단계는,

상기 I/O 요구에서의 암시 정보에 기초하여 명시 컨텍스트를 상기 제1 필터 드라이버에 전달하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 제1 필터로부터 필터 드라이버 등록 요구를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제5항에 있어서,

상기 프리-콜백 오더에서의 다른 필터 드라이버의 각각에 대하여 상기 프리-콜백 오더로 상기 제1 필터 드라이버를 정렬하는 것을 포함하여,

상기 요구에 따라 상기 제1 필터 드라이버를 등록하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제6항에 있어서,

상기 제1 필터 드라이버를 등록하는 상기 단계는,

특정 파일 시스템 볼륨용 필터 드라이버의 인스턴스를 등록하는 단계를 포함하는 것을 특징으로 하는 방법.
제7항에 있어서,

특정 파일 시스템 볼륨용으로 등록된 상기 필터 드라이버의 인스턴스는,

상기 볼륨용으로 등록된 상기 필터 드라이버의 다른 인스턴스와 동일한 종류의 필터 드라이버를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 제1 필터 드라이버는, 상기 제1 파일 시스템이 관련된 파일 I/O 요구의 적어도 한 종류의 세트를 나타내는 것을 특징으로 하는 방법.
제9항에 있어서,

파일 I/O 요구의 각 종류에 대하여,

상기 I/O 요구 종류와 관련된 각 필터 드라이버의 정렬을 나타내는 정렬 리스트를 구성하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 제2 파일 시스템 I/O 요구를 상기 파일 시스템에 전달한 후, 포스트-콜백 연산에서 상기 제1 파일 시스템 필터 드라이버 및 상기 최종 파일 시스템 필터 드라이버중 적어도 하나를 다시 호출하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 콜백에 응답하여 상기 제1 필터 드라이버로부터 상태값을 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 프리-콜백에 응답하여 상기 제1 필터 드라이버로부터 상태값을 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제13항에 있어서,

상기 상태값은 포스트-콜백으로 콜백되지 않도록 하는 요구 및 성공을 나타내고,

포스트-콜백으로 상기 제1 필터 드라이버를 호출하지 않고, 상기 제1 파일 시스템 I/O 요구에 대응하는 데이터를 상기 제1 파일 시스템 I/O 요구의 발생원에 리턴시키는 단계를 더 포함하는 것을 특징으로 하는 방법.
제13항에 있어서,

상기 상태값은 포스트-콜백으로 콜백되지 않도록 하는 요구 및 성공을 나타내고,

상기 I/O 요구에 대응하는 데이터를 상기 제1 필터 드라이버에 전달하는 것을 포함하여,

포스트-콜백 오더에 기초하여 포스트-콜백으로 제1 필터 드라이버를 호출하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제15항에 있어서,

상기 제1 필터 드라이버에 대한 상기 포스트-콜백에 응답하여 종료 상태를 나타내는 상태값을 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제15항에 있어서,

상기 제1 필터 드라이버에 대한 상기 포스트-콜백에 응답하여 추가 처리가 필요함을 나타내는 상태값을 수신하는 단계, 및

상기 제1 필터 드라이버로부터 상기 추가 처리가 완료됨을 나타내는 호를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제13항에 있어서,

상기 상태값은 진행중인 상태를 나타내며,

상기 진행중인 상태가 완료됨을 나타내는 호를 상기 제1 필터 드라이버로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제13항에 있어서,

상기 상태값은 동기 상태를 나타내는 것을 특징으로 하는 방법.
제13항에 있어서,

상기 상태값은 패스트 I/O가 허용되지 않음을 나타내는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 프리-콜백 오더는 각 필터 드라이버의 고도에 기초하며,

상기 제1 필터 드라이버에 의해 제공되는 정보에 기초하여 상기 제1 필터 드라이버용 고도를 구하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제21항에 있어서,

상기 고도가 구해진 상기 제1 필터 드라이버에 의해 제공되는 정보를 포함하는 등록 요구를 상기 제1 필터 드라이버로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

포스트-콜백 오더에 기초한 포스트-콜백으로 상기 제1 필터 드라이버를 호출하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제23항에 있어서,

상기 프리-콜백에 대하여 상기 제1 필터 드라이버용 데이터를 상기 제1 필터 드라이버에 보존하는 단계, 및

상기 포스트-콜백에 대하여 상기 보존된 데이터의 적어도 일부를 검색하고 상기 제1 필터 드라이버에 제공하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제23항에 있어서,

상기 제1 필터 드라이버용 데이터를 보존하는 상기 단계는, 데이터를 완료 노드 스택 상으로 푸시하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 최종 필터 드라이버가 포스트-콜백을 요구하였는지 여부를 결정하는 단계,

요구하였다면, a) 상기 프리-콜백에 대하여 상기 최종 필터 드라이버용 데이터를 상기 최종 필터 드라이버에 보존하는 단계, 및

b) 상기 보존된 데이터의 적어도 일부를 검색하고 상기 최종 필터 드라이버에 제공하는 단계를 포함하여, 포스트-콜백으로 상기 최종 필터 드라이버를 호출하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제26항에 있어서,

상기 최종 필터 드라이버용 보존하는 상기 단계는,

포스트-콜백에 대하여 보존된 다른 데이터를 상기 최종 필터 드라이버가 다른 필터 드라이버에 수정하였는지 여부를 결정하는 단계, 및

수정하지 않았다면 상기 다른 데이터를 상기 최종 필터 드라이버 및 상기 다른 필터 드라이버용으로 보존된 데이터로서 이용하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

컨텍스트를 상기 제1 필터 드라이버에 리턴하는 요구를 수신하는 단계 및 상기 요구에 응답하여 상기 컨텍스트에 대응하는 데이터를 리턴하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

컨텍스트 데이터를 상기 제1 필터 드라이버에 리턴하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 요구에 응답하여 리턴되는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 통지의 일부로서 리턴되는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 스트림 핸들에 대응하는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 스트림에 대응하는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 파일에 대응하는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 볼륨에 대응하는 것을 특징으로 하는 방법.
제29항에 있어서,

상기 컨텍스트 데이터는 인스턴스에 대응하는 것을 특징으로 하는 방법.
제29항에 있어서,

트리를 유지하는 단계, 및

상기 컨텍스트 데이터용 상기 트리를 탐색하는 단계

를 더 포함하는 것을 특징으로 하는 방법.
제29항에 있어서,

키를 수신하는 단계, 및

상기 키에 기초하여 키를 탐색하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제38항에 있어서,

상기 키는 파일 오브젝트 식별자 및 인스턴스 식별자를 포함하는 것을 특징으로 하는 방법.
제38항에 있어서,

상기 키는 인스턴스 식별자를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서,

상기 트리는 복수의 노드를 포함하며,

각 노드는 하나의 인스턴스에 대응하는 것을 특징으로 하는 방법.
제37항에 있어서,

상기 트리는 스트림에 대응하는 것을 특징으로 하는 방법.
제42항에 있어서,

상기 트리는 상기 파일 시스템에 의해 유지되는 다른 스트림 데이터에 논리적으로 부가되는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 파일 시스템측으로 향하는 제1 파일 시스템 I/O 요구를 수신하는 상기 단계는,

레거시 필터로부터 I/O 요구 패킷을 수신하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 파일 시스템측으로 향하는 상기 파일 시스템 I/O 요구는, 엔티티로부터 수신되는 I/O 요구 패킷을 포함하고,

대응하는 I/O 요구 패킷을 상기 엔티티에 리턴하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제45항에 있어서,

상기 제1 필터 드라이버로부터 수신한 콜백 데이터를, 상기 엔티티에 리턴되는 I/O 요구 패킷으로 재변환하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 파일 시스템측으로 향하여 상기 제1 파일 시스템 I/O 요구를 수신하는 상기 단계는,

레거시 필터로부터 I/O 요구 패킷을 수신하는 단계를 포함하는 것을 특징으로 하는 방법.
제47항에 있어서,

I/O 요구 패킷을 상기 레거시 필터에 리턴하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 제1 필터 드라이버에서 개시된 다른 I/O 요구를 수신하는 단계, 및

상기 다른 I/O 요구에 대응하는 콜백 데이터로 적어도 다른 하나의 필터 드라이버를 프리-콜링하는 것을 포함하여, 상기 다른 I/O 요구를 상기 파일 시스템측으로 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제49항에 있어서,

상기 다른 I/O 요구는 파일 생성 요구를 포함하고,

상기 요구를 개시함에 따라 상기 제1 필터 드라이버를 식별하는 힌트를 갖는 파일을 생성하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항에 기재된 방법을 수행하기 위한 컴퓨터로 실행가능한 명령을 갖는 컴퓨터로 판독가능한 매체.
파일 시스템 관련 기능 호를 수신하고 대응하는 I/O 요구 데이터를 상기 파일 시스템측에 제공하는 구성 요소를 포함하는 운영 시스템, 및 파일 시스템을 갖는 컴퓨팅 환경에서, 상기 시스템은,

복수의 필터 드라이버; 및

필터 매니저를 포함하고, 상기 필터 매니저는,

a) 상기 필터 드라이버 각각을 등록하고,

b) 상기 필터 드라이버를 적어도 하나의 프리-콜백 오더로 정렬하고, - 각 프리-콜백 오더는 하나 이상의 상기 필터 드라이버의 한 세트에 대응함 -

c) 상기 요구 데이터를 수신하고,

d) 호출된 각 필터 드라이버에 대한 요구에 기초하여 콜백 데이터를 제공하는 것을 포함하여, 선택된 프리-콜백 오더에 기초하여 상기 필터 드라이버중 적어도 하나를 호출하고,

e) 호출된 각 필터 드라이버로부터 상태를 수신하고,

f) 상기 콜백 데이터에 대응하는 데이터를 포함하는 I/O 요구를 상기 파일 시스템측에 전달하는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 I/O 요구 데이터는 I/O 요구 패킷내의 정보를 포함하는 것을 특징으로 하는 시스템.
제53항에 있어서,

상기 필터 매니저는 상기 I/O 요구 패킷을 콜백 데이터로 변환하는 것을 특징으로 하는 시스템.
제54항에 있어서,

상기 필터 매니저는, 상기 I/O 요구내의 암시 정보에 기초하여 명시 컨텍스트를 상기 제1 필터 드라이버에 전달함으로써, 상기 I/O 요구 패킷을 콜백 데이터 로 변환하는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 선택된 프리-콜백 오더는, 제1 필터 및 최종 필터를 포함하고,

상기 제1 필터는, 상기 필터 매니저가 프리-콜백으로 필터를 호출하는 순서에 대하여 상기 최종 필터 전에 정렬되는 것을 특징으로 하는 시스템.
제56항에 있어서,

상기 선택된 프리-콜백 오더는, 상기 필터 매니저가 프리-콜백으로 필터를 호출하는 순서에 대하여 상기 제1 필터 후이고 상기 최종 필터 전에 정렬된 중간 필터를 포함하는 것을 특징으로 하는 시스템.
제52항에 있어서,

각 필터는 특정 파일 시스템 볼륨용으로 등록된 필터 드라이버의 인스턴스를 포함하는 것을 특징으로 하는 시스템.
제58항에 있어서,

특정 파일 시스템 볼륨용으로 등록된 필터 드라이버의 적어도 2개의 인스턴스는 동일한 종류의 필터 드라이버를 포함하는 것을 특징으로 하는 시스템.
제52항에 있어서,

각 필터 드라이버는 필터 드라이버가 프리-콜백을 수신하는데 관련된 적어도 한 종류의 파일 I/O 요구를 나타내는 것을 특징으로 하는 시스템.
제60항에 있어서,

각 프리-콜백 오더는 파일 I/O 요구의 종류에 대응하고,

상기 필터 매니저는, 각 필터 드라이버가 프리-콜백을 수신하는데 관련되었음을 나타내는 상기 파일 I/O 요구 종류 또는 종류들에 기초하여 상기 필터 드라이버를 각 프리-콜백 오더로 배열하는 것을 특징으로 하는 시스템.
제61항에 있어서,

하나 이상의 식별된 필터 드라이버에 대한 각 프리-콜백 오더에 대하여,

상기 필터 매니저는, 각 필터 드라이버와 관련된 고도에 기초하여 프리-콜백 오더내에 상기 필터 드라이버를 순서화하는 것을 특징으로 하는 시스템.
제62항에 있어서,

상기 필터 매니저는, 각 필터 드라이버와 관련된 고도를 상기 필터 드라이버에 의해 제공되는 정보로부터 구하는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 필터 드라이버는 포스트-콜백 연산에서 적어도 하나의 필터 드라이버를 콜백하는 것을 특징으로 하는 시스템.
제64항에 있어서,

상기 제1 필터 드라이버에 대한 상기 포스트-콜백에 응답하여 완료 상태를 나타내는 상태값을 수신하는 것을 특징으로 하는 시스템.
제64항에 있어서,

상기 제1 필터 드라이버에 대한 상기 포스트-콜백에 응답하여 추가 처리가 필요함을 나타내는 상태값을 수신하는 것을 특징으로 하는 시스템.
제52항에 있어서,

호출된 필터 드라이버로부터 수신된 상기 상태값은, 성공, 및 포스트-콜백으로 콜백되지 않아야 하는 요구를 나타내는 것을 특징으로 하는 시스템.
제52항에 있어서,

호출된 필터 드라이버로부터 수신된 상기 상태값은, 성공, 및 포스트-콜백으로 콜백되어야 하는 요구를 나타내는 것을 특징으로 하는 시스템.
제52항에 있어서,

호출된 필터 드라이버로부터 수신된 상기 상태값은 진행중인 상태를 나타내며,

상기 제1 필터 드라이버는, 다른 임의의 필터 드라이버를 호출하기 전에 상기 진행중인 상태가 완료됨을 나타내는, 상기 호출된 필터 드라이버로부터의 정보를 대기하는 것을 특징으로 하는 시스템.
제52항에 있어서,

호출된 필터 드라이버로부터 수신된 상기 상태값은 동기 상태를 나타내는 것을 특징으로 하는 시스템.
제52항에 있어서,

호출된 필터 드라이버로부터 수신된 상기 상태값은, 패스트 I/O가 허용되지 않음을 나타내는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 필터 매니저는, 프리-콜백으로 호출된 상기 필터 드라이버중 적어도 하나를 위한 파라미터 정보를 보존하고, 포스트-콜백 연산동안 상기 보존된 파라미터 정보의 적어도 일부를 검색하여 상기 적어도 하나의 필터 드라이버에 제공하는 것을 특징으로 하는 시스템.
제72항에 있어서,

상기 필터 매니저는 데이터를 완료 노드 스택에 푸시함으로써 상기 파라미터 정보를 보존하는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 필터 매니저는 컨텍스트를 필터 드라이버에 리턴하는 요구를 수신하고,

상기 필터 매니저는 상기 요구에 응답하여 상기 컨텍스트에 대응하는 데이터를 리턴하는 것을 특징으로 하는 시스템.
제52항에 있어서,

필터 드라이버에 논리적으로 리턴되는 컨텍스트 구조를 더 포함하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 상기 필터 드라이버로부터의 요구에 응답하여 상기 피터 드라이버에 리턴되는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 상기 스트림 핸들에 대응하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 스트림에 대응하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 파일에 대응하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 볼륨에 대응하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 컨텍스트 구조는 인스턴스에 대응하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 필터 매니저는 스트림과 관련된 노드 트리를 유지하고,

각 노드는 인스턴스를 나타내며,

상기 필터 드라이버는, 파일 오브젝트 식별자 및 인스턴스 식별자를 상기 필터 매니저에, 상기 트리에서의 정보에 기초하여 상기 컨텍스트 구조를 위치 지정하기 위한 키로서 제공하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 필터 매니저는 스트림과 관련된 노드 트리를 유지하고,

각 노드는 인스턴스를 나타내며,

상기 필터 드라이버는, 인스턴스 식별자를 상기 필터 매니저에, 상기 트리에서의 정보에 기초하여 상기 컨텍스트 구조를 위치 지정하기 위한 키로서 제공하는 것을 특징으로 하는 시스템.
제75항에 있어서,

상기 필터 매니저는 스트림과 관련된 노드 트리를 유지하고,

상기 트리는 상기 스트림을 위해 상기 파일 시스템에 의해 유지되는 다른 스트림 데이터에 논리적으로 부가되는 것을 특징으로 하는 시스템.
제52항에 있어서,

상기 I/O 요구 데이터를, 상기 운영 시스템 구성 요소로부터 상기 파일 시스템으로 향하는 패킷으로서 수신하며,

상기 I/O 요구 데이터를 상기 필터 매니저에 패킷으로서 제공하는 레거시 필터를 더 포함하는 것을 특징으로 하는 시스템.
제85항에 있어서,

상기 파일 매니저는, 상기 I/O 요구를 상기 파일 시스템측으로 전달한 후 I/O 요구 패킷을 상기 레거시 필터에 리턴하는 것을 특징으로 하는 시스템.
제85항에 있어서,

상기 필터 매니저는, 상기 필터 드라이버에서 개시된 나머지 I/O 요구에 대응하는 콜백 데이터로 적어도 다른 하나의 필터 드라이버를 프리-콜링한 후,

필터 드라이버에서 개시된 다른 I/O 요구를 수신하고 상기 필터 드라이버에서 개시된 상기 나머지 I/O 요구를 상기 파일 시스템측으로 전송하는 것을 특징으로 하는 시스템.
제87항에 있어서,

상기 나머지 I/O 요구는 파일 생성 요구를 포함하며,

상기 필터 드라이버는 상기 제1 필터 드라이버를 식별하기 위한 힌트로 상기 파일 생성을 요구하는 것을 특징으로 하는 시스템.
데이터 구조가 내장되어 있는 컴퓨터로 판독가능한 매체로서,

상기 데이터 구조를 파일 시스템 I/O 요구 종류와 관련된 것으로서 식별하는 제1 세트의 정보;

상기 파일 시스템 I/O 요구 종류와 관련된 복수의 필터 드라이버를 식별하는 제2 세트의 정보; 및

서로에 대하여 상기 필터 드라이버의 정렬을 식별하는 제3 세트의 정보를 포함하고,

상기 제1 세트의 정보에 대응하는 파일 시스템 I/O 요구에 응답하여, 엔티티는, 상기 제3 세트의 정보에 의해 결정되는 순서로 프리-콜백으로 상기 제2 세트에서의 필터 드라이버 각각을 호출하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제1 세트의 정보는 파일 생성에 관한 파일 시스템 I/O 요구에 대응하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제1 세트의 정보는 파일을 여는 것에 관한 파일 시스템 I/O 요구에 대응하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제1 세트의 정보는 파일로부터의 판독에 관한 파일 시스템 I/O 요구에 대응하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제1 세트의 정보는 파일 기록에 관한 파일 시스템 I/O 요구에 대응하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제1 세트의 정보는 파일 종료에 관한 파일 시스템 I/O 요구에 대응하는 것을 특징으로 하는 컴퓨터 판독가능 매체.
제89항에 있어서,

상기 제2 세트의 정보는, 호출하는 필터 드라이버의 리스트를 포함하고,

상기 필터 드라이버의 정렬을 식별하는 상기 제3 세트의 정보는 상기 리스트내의 필터 드라이버의 순서 내에 통합되는 것을 특징으로 하는 컴퓨터 판독가능 매체.
컴퓨팅 환경에서,

상위 필터 드라이버보다 밑에 있고 하위 필터 드라이버보다 위에 있는 중간 필터 드라이버를 포함하는 복수의 필터 드라이버를 콜백 오더로 등록하는 단계;

상기 중간 필터 드라이버에서 개시되는 파일 시스템 지시 I/O 요구를 수신하는 단계;

상기 중간 필터 드라이버에 의해 상기 I/ 요구가 개시되었음을 나타내는 정보를 유지하는 단계;

상기 I/O 요구를 상기 파일 시스템측으로 전송하는 단계;

상기 I/O 요구에 대응하는 상기 파일 시스템으로부터 상태 데이터를 수신하는 단계;

상기 상태 데이터를, 상기 I/O 요구를 개시한 상기 중간 필터 드라이버에 리턴하는 단계; 및

상기 상태 데이터가 상기 상위 필터 드라이버에 전달되지 않도록 상기 I/O 요구가 상기 중간 필터 드라이버에 의해 개시되었음을 나타내는 상기 정보를 액세스하는 단계

를 포함하는 것을 특징으로 하는 방법.
제96항에 있어서,

상기 I/O 요구에 대응하는 콜백 데이터로 상기 하위 필터 드라이버를 프리 콜링하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제97항에 있어서,

상기 상태 데이터에 대응하는 콜백 데이터로 상기 하위 필터 드라이버를 포스트 콜링하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제96항에 있어서,

상기 I/O 요구는 파일 생성 요구를 포함하고,

상기 정보를 유지하는 단계는, 상기 중간 필터 드라이버가 상기 요구를 개시한 것으로 식별하는 힌트로 파일 생성을 요구하는 단계를 포함하는 것을 특징으로 하는 방법.
제99항에 있어서,

상기 생성된 파일에 대응하는 상기 중간 필터 드라이버에서 개시된 기록 요구를 수신하는 단계;

상기 기록 요구를 상기 파일 시스템측으로 전송하는 단계;

상기 기록 요구에 대응하는 상기 파일 시스템으로부터 다른 세트의 상태 데이터를 수신하는 단계;

나머지 세트의 상태 데이터를 상기 중간 필터 드라이버에 리턴하는 단계; 및

상기 나머지 상태 데이터가 상기 상위 필터 드라이버에 전달되지 않도록, 상기 정보에 액세스하여 상기 나머지 세트의 상태 데이터가 힌트를 갖고 생성된 파일에 대응하는지 여부를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제99항에 있어서,

상기 생성된 파일에 대응하는 상기 중간 필터 드라이버에서 개시된 판독 요구를 수신하는 단계;

상기 판독 요구를 상기 파일 시스템측으로 전송하는 단계;

상기 판독 요구에 대응하는 상기 파일 시스템으로부터 다른 세트의 상태 데이터를 수신하는 단계;

상기 나머지 세트의 상태 데이터를 상기 중간 필터 드라이버에 리턴하는 단계; 및

상기 나머지 상태 데이터가 상기 상위 필터 드라이버에 전달되지 않도록, 상기 정보에 액세스하여 상기 나머지 세트의 상태 데이터가 힌트를 갖고 생성된 파일에 대응하는지 여부를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.