BRPI0305401B1 - método e sistema em um ambiente de computação e meio legível por computador - Google Patents

Abstract

"modelo e arquitetura de filtro de sistema de arquivo gerenciado". trata-se de um modelo no qual acionadores de filtro são gerenciados para receber rechamadas de pedidos de i/o nos quais os acionadores de filtro registraram um interesse. as instâncias por volume de acionadores de filtro registram com um gerenciador de filtro para pré-rechamadas (para i/o até o sistema de arquivo) e pós-rechamadas (para i/o a partir do sistema de arquivo), e identificam quais pedidos de i/o (por exemplo, criar, ler, gravar) estes estão registrando para receber rechamadas. o gerenciador de filtro ordena as instâncias para rechamadas. quando um pedido de i/o é recebido, o gerenciador de filtro converte o pedido de i/o em dados de rechamada e chama os filtros interessados na ordem de rechamada, pelo qual as instâncias de filtro podem processar os dados de i/0. a medida em que o pedido retorna do sistema de arquivo, os filtros que desejam pós-rechamadas são chamados na ordem inversa. o gerenciamento de contexto eficiente para os filtros e outras funções, tais como i/o de arquivo não reentrante, são também proporcionados pelo modelo.

Description

Relatório Descritivo da Patente de Invenção para "MÉTODO E SISTEMA EM UM AMBIENTE DE COMPUTAÇÃO E MEIO LEGÍVEL POR COMPUTADOR".

CAMPO DA INVENÇÃO

[001] A invenção refere-se geral mente a sistemas de computador e, mais particularmente, a sistemas de arquivo e filtros de sistemas de arquivo.

ANTECEDENTES DA INVENÇÃO

[002] Com sistemas operacionais contemporâneos, tal como o sistema operacional Windows' XP da Microsoft Corporation com um sistema de arquivo subjacente tal como sistema de arquivos redirecio-nadores Windows" NFTS (Windows" NT File System), FAT, CDFS, SMB, ou sistemas de arquivo WebDav, um ou mais acionadores de filtro de arquivo de sistema podem ser inseridos entre o gerenciador l/O que recebe os pedidos de l/O de usuário e o acionador de sistema de arquivo. Em geral, acionadores de filtro ('filtros1) são acionadores de modo kernel que aumentam o sistema de arquivo subjacente ao executar diversas tarefas de computação relacionadas a arquivo que os usuários desejarem, incluindo tarefas como passar o sistema de arquivo l/O (pedidos e dados) através de software anti-vírus, provedores de cota de sistema de arquivo, replicadores de arquivo e produtos de compressão/criptografia. Por exemplo, produtos anti-vírus proporcionam um filtro que observa l/O até e a partir de certos tipos de arquivo ( exe, .doc, e similares) que procuram assinaturas de vírus, ao mesmo tempo em que os produtos de replicação de arquivo executam imagem refletida de nível de sistema de arquivo. Outros tipos de acionadores de filtro de sistema de arquivo são dirigidos à restauração de sistema (que copia arquivos de sistema quando alterações estão perto de serem feitas para que o usuário possa retornar ao estado original), execução de cota de disco, cópia de segurança de arquivos abertos, re- cuperação de arquivos eliminados, criptografia de arquivos, e assim por diante. Desta maneira, ao instalar acionadores de filtro de sistema de arquivo, os usuários de computador podem selecionar as características de sistema de arquivo que quiserem e precisarem, de maneira que permita atualizações, substituição, inserção, remoção dos componentes sem precisar mudar o sistema operacional real ou código de acionador de sistema.

[003] O modelo de filtro de sistema de arquivo existente em sistemas operacionais contemporâneos baseados em Windows® (por exemplo, Servidor Windows® NT, Windows® 2000, Windows® XP, Windows®.NET 2003) alavanca o modelo l/O inerente, que é uma abordagem baseada em pacote. Para esse fim, filtros de sistema de arquivo carregam como acionadores regulares em uma pilha e anexam aos objetos de dispositivo de volume do sistema de arquivo subjacente. Os pedidos de l/O de usuário são convertidos através de um gerenciador de l/O em Pacotes de Pedido de l/O (IRPs), que são enviados à pilha de acionador e processados pelo acionador superior, que pode completá-la, passá-la em uma chamada para outro acionador em direção ao sistema de arquivo, que chama o próximo acionador inferior, e assim por diante. Em geral, cada acionador realiza qualquer processamento que é codificado para executar sobre o IRP, e então passa o IRP de forma explícita até o próximo acionador inferior (ou sistema de arquivo se nenhum for inferior), ou completa (ou falha) o IRP e envia-o de volta à pilha para o próximo acionador superior (ou o gerenciador de l/O se nenhum for superior).

[004] Embora este modelo de acionador de filtro existente proporcione inúmeros benefícios incluindo ser altamente flexível, há também inúmeros problemas inerentes com o mesmo. Para alguém, gravar um filtro de sistema de arquivo não é uma tarefa trivial, principalmente em decorrência da complexibilidade de um sistema de arquivo.

Os filtros são peças altamente complexas de software que são tradicionalmente difíceis de depurar e manter. Muito dessa complexibilidade surge do manejamento de filtros dos pacotes, por exemplo, a necessidade de compreender e manipular IRPs. Como resultado, sofre confiabilidade, e pelo menos um estudo mostrou que os filtros são responsáveis por uma porcentagem significativa de falhas de sistema.

[005] Outro problema é eficiência, como os filtros de sistema de arquivo recebem e processam tradicionalmente cada operação que normalmente vai de um sistema de arquivo, mesmo nas quais estes não têm nenhum interesse. Por exemplo, um produto anti-vírus pode diminuir a velocidade de um sistema em até sessenta por cento, porém nem todo pedido de l/O recebido por um filtro anti-vírus é aquele que o filtro irá fazer algo, isto é, examinar quaisquer dados correspondentes a vírus. A redundância é também um problema que leva à insuficiência e custo de computação, uma vez muitos filtros fazem as mesmas coisas de maneiras diferentes, levando a código desnecessário.

[006] A interoperabilidade entre os acionadores é também um problema significativo, como, por exemplo, um acionador pode modificar a l/O de um modo que o outro acionador não antecipe e não possa lidar propriamente. Nota-se que os problemas de interoperabilidade são um dos maiores inconvenientes do modelo existente, em parte porque os filtros possuem somente um controle de granulação muito grosseira com relação à solicitação de inclusão no sistema de arquivo.

[007] Outros problemas incluem estouro da capacidade do espaço da pilha, porque quando dois ou mais filtros são instalados, estouros da capacidade da pilha são comuns devido ao l/O reentrante re-cursivo emitido pelos filtros. Impasses são também comuns no modelo existente, de novo principalmente devido ao l/O reentrante. Outros problemas incluem a incapacidade de carregar e descarregar de forma dinâmica os filtros na pilha, ou seja, sem uma reinicialização do sistema.

[008] Em suma, o modelo de acionador de filtro existente possui inúmeros inconvenientes significativos. Necessita-se um modelo e arquitetura aperfeiçoados para filtros de sistema de arquivo manipularem os pedidos de l/O de sistema de arquivo e dados associados. SUMÁRIO DA INVENÇÃO

[009] Em suma, a presente invenção proporciona um mode-lo/arquitetura no qual os acionadores de filtro são gerenciados por um gerenciador de filtro para receber retribuições de chamadas para pedidos de l/O nos quais os acionadores de filtro registraram interesse. O modelo elimina passagem l/O complexa tradicional ao proporcionar um modelo de retribuição de chamada gerenciada, no qual IRPs, trajetórias l/O rápidas, retribuições de chamadas de Filtro Fs e assim por diante são traduzidos por um gerenciador de filtro em retribuições de chamadas que proporcionam dados de retribuição de chamada em um formato explícito bem definido dentro dos filtros. Os filtros manipulam os dados de retribuição de chamada como desejado, e retornam ao estado em resposta à retribuição de chamada, como descrito abaixo. Como um resultado, os filtros não têm mais de lidar com IRPs.

[0010] Em geral, um gerenciador de filtro traduz a l/O, se for um IRP, l/O rápida, retribuição de chamada de Filtro Fs ou similar, em uma estrutura uniforme conhecida como “dados de retribuição de chamada". Para esse fim, o gerenciador de filtro pode ser colocado dentro da pilha de acionador de filtro de legado como se fosse um acionador de filtro de legado, de modo que o mesmo possa receber e processar IRPs. O gerenciador de filtro percorre então uma lista de acionadores de filtro apropriadamente registrados para solicitar um envio registrado para a l/O.

[0011] Os acionadores de filtro podem compreendem objetos (ou tais componentes similares) que quando instanciados registram com um mecanismo de registro no gerenciador de filtro. Os acionadores de filtro registram somente para pedidos de sistema de arquivo nos quais estes podem estar interessados em processamento, ao notificar o gerenciador de filtro dos tipos de pedidos de l/O nos quais está interessado (por exemplo, criar, ler, gravar, fechar e assim por diante). Como resultado, o modelo é mais eficiente que um modelo de filtro empilhado, devido aos acionadores de filtro não verem os pedidos 1/0 em que eles não estão interessados, e desta maneira não registrados.

[0012] Em uma implementação, os acionadores de filtro anexam-se separadamente aos volumes como instâncias de acionador de filtro, em uma base por volume, e um acionador de filtro pode anexar múltiplas instâncias ao mesmo volume. Cada instância de acionador de filtro é associada a uma ‘altitude’, que indica onde na ordem de retribuição de chamada o acionador está localizado. A altitude pode ser pré-definida, ou derivada de sinalizadores proporcionados pelo acionador que indica o tipo de processamento que o acionador irá executar sobre os dados de retribuição de chamada.

[0013] Para rastrear de forma eficiente quais acionadores de filtro foram registrados para quais tipos de retribuições de chamadas e desse modo rechamar de forma eficiente os acionadores apropriados na ordem própria, o gerenciador de filtro mantém por volume, listas ordenadas, cada lista indicada por um tipo de operação para que os filtros registrados se interessem em receber pré-retribuições de chamadas e/ou pós-retribuições de chamadas. O gerenciador de filtro utiliza esta lista para rechamar os filtros na ordem apropriada, e cada filtro retorna a um estado. Ao admitir bom resultado, após a última retribuição de chamada, o gerenciador de filtro reconverte os dados de retribuição de chamada para um IRP e envia o IRP para o sistema de arquivo.

[0014] As pós-retribuições de chamadas funcionam essencialmen- te na ordem oposta, embora um filtro possa indicar que precisa ser ignorada durante as pós-retribuíções de chamadas. A conclusão de l/O é manipulado pelo gerenciador de filtro de modo que garanta que os parâmetros observados pela instância de filtro em sua pré-retribuição de chamada sejam os mesmos em suas pós-retribuiçoes de chamadas. Para essa finalidade, o gerenciador de filtro mantém uma conclusão de fila de nó que a mesma acessa para retornar aos parâmetros corretos em cada pós-retribuição de chamada [0015] O gerenciador de filtro também proporciona um rico conjunto de API que proporciona funções que os filtros normalmente precisam. Por exemplo, certos filtros precisam realizaras suas próprias l/O, e várias funções são proporcionadas para facilitar tais operações. Várias funções também proporcionam suporte de contexto eficiente com instâncias, volumes, arquivos, ponteiro de fluxo, ou fluxo que mantém a trilha dos dados de contexto para cada filtro em associação com o objeto apropriado. A presente invenção proporciona suporte de notificação através de um conjunto de retribuições de chamadas que configura a notificação para uma entidade, e simplifica a associação de um contexto por filtro com aquela entidade. Os contextos podem ser estabelecidos e/ou restabelecidos a qualquer momento. Ainda outras funções permitem comunicação entre acionadores de filtro de modo ker-nel e serviços e programas de parte contrária de modo de usuário, enquanto outras funções proporcionam suporte de nomeação como descrito no Pedido de Patente US 10/187119, depositado em 28 de agosto de 2002.

[0016] Outras vantagens tornar-se-ão óbvias a partir da descrição detalhada, quando tomada em conjunto com os desenhos.

BREVE DESCRIÇÃO DOS DESENHOS

[0017] A Figura 1 é um diagrama de blocos que representa geralmente um sistema de computador no qual a presente invenção pode ser incorporada; A Figura 2 é um diagrama de blocos que representa geralmente uma arquitetura que inclui componentes para gerenciar a l/O para filtros de acordo com um aspecto da presente invenção; A Figura 3 é um diagrama de blocos que representa geralmente instâncias de filtros gerenciados de acordo com um aspecto da presente invenção; A Figura 4 é um diagrama de blocos que representa geralmente estruturas de dados utilizadas por um gerenciador de filtro para passar de forma seletiva 1/0 para filtros apropriadamente registrados de acordo com um aspecto da presente invenção; A Figura 5 é uma representação de uma fila de nós de terminação para retornar os dados de retribuição de chamada para os acionadores de filtro registrados em uma operação de pós-retribuição de chamada de acordo com um aspecto da presente invenção; A Figura 6 é um diagrama de blocos que representa uma árvore para determinação eficiente de quais instâncias possuem dados de contexto de acordo com um aspecto da presente invenção; e A Figura 7 é um diagrama de blocos que representa o retorno de dados de contexto para um acionador de filtro de acordo com um aspecto da presente invenção.

DESCRIÇÃO DETALHADA AMBIENTE OPERACIONAL EXEMPLIFICATIVO

[0018] A Figura 1 ilustra um exemplo de um ambiente de sistema de computação adequado 100 sobre o qual a invenção pode ser implementada. O ambiente de sistema de computação 100 é apenas um exemplo de um ambiente de computação adequado e não pretende sugerir qualquer limitação quanto ao escopo de uso ou funcionalidade da invenção. Nem o ambiente de computação 100 deve ser interpretado como tendo qualquer dependência ou requerimento com relação a qualquer um ou combinação de componentes ilustrados no ambiente operacional exemplificativo 100.

[0019] A invenção é operacional com inúmeros outros propósitos gerais ou propósitos especiais em ambientes de configuração de sistema de computação. Exemplos de sistemas de computação, ambientes e/ou configurações bem conhecidos que podem ser adequados para uso com a invenção incluem, porém sem caráter limitativo, computadores pessoais, computadores de servidor, dispositivos manuais ou portáteis, dispositivos de mesa gráfica, sistemas multiprocessadores, sistemas baseados em microprocessadores, aparelhos decodifi-cadores, eletrônicos de cliente programáveis, Pcs de rede, minicompu-tadores, computadores de grande porte, ambientes de computação distribuídos que incluam qualquer um dos sistemas ou dispositivos acima, e similares.

[0020] A invenção pode ser descrita no contexto geral das instruções executáveis de computador, tais como módulos de programa, que são executados por um computador. Geralmente, os módulos de programa incluem rotinas, programas, objetos, componentes, estrutura de dados, e assim por diante, que executam tarefas particulares ou implementam tipos de dados de abstração particulares. A invenção pode ser praticada em ambientes de computação distribuídos onde as tarefas são executadas através de dispositivos de processamento remoto que são vinculados através de uma rede de comunicação. Em um ambiente de computação distribuído, os módulos de programa podem ser localizados tanto em mídia de armazenamento de computador local como remota que inclui dispositivos de armazenamento de memória.

[0021] Com referência à Figura 1, um sistema exemplificativo para implementar a invenção inclui um dispositivo de computação de propósito geral na forma de um computador 110. Os componentes do computador 110 podem incluir, porém não limitados à, uma unidade de processamento 120, uma memória de sistema 130, e um barramento de sistema 121 que acopla diversos componentes de sistema que incluem a memória de sistema para a unidade de processamento 120. O barramento de sistema 121 pode ser qualquer um dos diversos tipos de estruturas de barramento que incluem um barramento de sistema ou controlador de memória, um barramento periférico, e um barramento local que utiliza qualquer de uma variedade de estruturas de barramento. À guisa de exemplo, e sem caráter limitativo, tais estruturas incluem barramento Industry Standard Architecture (ISA), barramento Micro Channel Architecture (MCA), barramento Enhanced ISA (EISA), barramento local Eletronics Standards Association (VESA), e barramento Peripheral Component Interconnect (PCI) também conhecido como barramento Mezzanine.

[0022] O computador 110 inclui tipicamente uma variedade de mídia legível por computador. A mídia legível por computador pode ser qualquer mídia disponível que possa ser acessada pelo computador 110 e inclua tanto mídia volátil como não volátil, e mídia removível e não removível. À guisa de exemplo, e sem caráter limitativo, a mídia legível de comutador pode compreender mídia de armazenamento de computador e mídia de comunicação. A mídia de armazenamento de computador inclui tanto mídia volátil como não volátil, removível e não removível implementada em qualquer método ou tecnologia para armazenamento de informação tal como instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados. A mídia de armazenamento de computador inclui, porém não limitada à, RAM, ROM,EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento de disco óptico, cassetes magnéticos, fita magnética, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para armazenar as informações desejadas e que possa ser acessado pelo computador 110. A mídia de comunicação concretiza tipicamente instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados em um sinal de dados modulados tal como uma onda portadora ou outro mecanismo de transporte e inclui qualquer mídia de entrega de informações. O termo “sinal de dados modulados” significa um sinal que possui uma ou mais de suas características estabelecidas ou alteradas de tal modo para codificar informações no sinal. À guisa de exemplo, e sem caráter limitativo, a mídia de comunicação inclui mídia com fio tal como uma rede com fio ou conexão direta com fio, e mídia sem fio tal como acústica, RF, infravermelho e outra mídia sem fio. As combinações de qualquer destes acima devem ser também incluídas dentro do escopo de mídia legível por computador.

[0023] A memória de sistema 130 inclui mídia de armazenamento de computador na forma de memória volátil e/ou não volátil tal como memória somente de leitura (ROM) 131 e memória de acesso randô-mico (RAM) 132. Um sistema básico de entrada/saída 133 (BIOS), que contém as rotinas básicas que ajudam a transferir informações entre elementos dentro do computador 110, tal como durante a partida, é tipicamente armazenado em ROM 131. A RAM 132 contém tipicamente dados e/ou módulos de programa que são imediatamente acessíveis e/ou que são atualmente operados através de unidade de processamento 120. À guisa de exemplo, e sem caráter limitativo, a Figura 1 ilustra sistema operacional 134, sistema de arquivo 135, programas de aplicação 136, outros módulos de programa 137 e dados de programa 138.

[0024] O computador 110 pode também incluir outra mídia de armazenamento de computador removível/não removível, volátil/não volátil. Somente à guisa de exemplo, a Figura 1 ilustra uma unidade de disco rígido 141 que lê a partir de ou grava até mídia magnética não removível não volátil, uma unidade de disco magnético 151 que lê a partir de ou grava até um disco magnético removível não volátil 152, e uma unidade disco óptico 155 que lê a partir de ou grava até um disco óptico removível não volátil 156 tal como um CD ROM ou outra mídia óptica. Outra mídia de armazenamento de computador removível/não removível, volátil/não volátil que pode ser usada no ambiente operacional exemplificativo inclui, porém não limitada à, cassetes de fita magnética, placas de memória flash, discos versáteis digitais, fita de vídeo digital, RAM em estado sólido, ROM em estado sólido, e similar. A unidade de disco rígido 141 é tipicamente conectada ao barramento de sistema 121 através de uma interface de memória removível tal como interface 140, e unidade de disco magnético 151 e unidade de disco óptico 155 são tipicamente conectadas ao barramento de sistema 121 através de uma interface de memória removível, tal como interface 150.

[0025] As unidades de disco e suas mídias de armazenamento de computador associadas, discutidas acima e ilustradas na Figura 1, proporcionam armazenamento de instruções legíveis por computador, estruturas de dados, módulos de programa e outros dados para o computador 110. Na Figura 1, por exemplo, a unidade disco rígido 141 é ilustrada como sistema operacional de armazenamento 144, programas de aplicação 145, outros módulos de programa 146 e dados de programa 147. Nota-se que estes componentes podem tanto ser os mesmos como diferentes do sistema operacional 134, programas de aplicação 136, outros módulos de programa 137, e dados de programa 138. O sistema operacional 144, programas de aplicação 145, outros módulos de programa 146, e dados de programa 147 são dados números diferentes no presente documento para ilustrar que, no mínimo eles são cópias diferentes. Um usuário pode ingressar em comandos e informações dentro do computador 110 através de dispositivos de entrada tais como uma mesa gráfica (digitalizador eletrônico) 164, um microfone 163, um teclado 162 e um dispositivo de indicação 161, co-mumente referido como mouse, cursor trackball, mesa sensível ao toque. Outros dispositivos de entrada (não mostrados) podem incluir um joystick, sensor de jogo, satélite parabólico, dispositivo de varredura, ou similares. Estes e outros dispositivos são freqüentemente conectados à unidade de processamento 120 através de uma interface de entrada com o usuário 160 que é acoplada ao barramento de sistema, porém pode ser conectada através de outra interface e estruturas de barramento, tais como porta paralela, porta de jogos ou um barramento serial universal (USB). Um monitor 191 ou outro tipo de dispositivo de monitor de vídeo é também conectado ao sistema de barramento 121 através de uma interface, tal como interface de vídeo 190. O monitor 191 pode ser também integrado com um painel de tela sensível ao toque ou similar. Nota-se que o monitor e/ou painel de tela sensível ao toque pode ser fisicamente acoplado em um alojamento no qual o dispositivo de computação 110 é incorporado, tal como em um computador pessoal do tipo mesa gráfica. Ademais, computadores tal como o dispositivo de computação 110 pode também incluir outros dispositivos de saída periféricos tais como auto falantes 195 e impressora 196, que podem ser conectados através de uma interface periférica de saída 194 ou similar.

[0026] O computador 110 pode operar em um ambiente de rede que utiliza conexões lógicas para um ou mais computadores remotos, tal como um computador remoto 180. O computador remoto 180 pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo de rede não hierárquica ou outro nó de rede comum, e inclui tipicamente muitos ou todos os elementos descritos acima com relação ao computador 110, embora somente um dispositivo de armazenamento de memória 181 seja ilustrado na Figura 1. As conexões lógicas mostradas na Figura 1 incluem uma rede de área local (LAN) 171 e uma rede remota (WAN) 173, porém pode incluir também outras redes. Tais ambientes de rede são comuns em escritórios, redes de computador empresarial corporativa, intranet e a Internet. Por exemplo, na presente invenção, o sistema de computador 110 pode compreender máquina-fonte a partir da qual dados são emigrados, e o computador remoto 180 pode compreender a máquina de destino. No-ta-se entretanto que as máquinas fonte e de destino não precisam ser conectadas através de uma rede ou qualquer outro meio, porém em vez disso, os dados podem ser emigrados através de qualquer meio capaz de ser gravado pela plataforma-fonte e lido pela plataforma ou plataformas de destino.

[0027] Quando usado em um ambiente de rede LAN, o computador 110 conecta-se à LAN 171 através de uma interface de rede ou adaptador 170. Quando usado em um ambiente de rede WAN, o computador 110 inclui tipicamente um modem 172 ou outro meio para estabelecer comunicações com relação à WAN 173, tal como a Internet. O modem 172, que pode ser interno ou externo, pode ser conectado ao barramento de sistema 121 através da interface de entrada com o usuário 160 ou outro mecanismo apropriado. Em um ambiente de rede, os módulos de programa mostrados com relação ao computador 110, ou partes dos mesmos, podem ser armazenados no dispositivo de armazenamento de memória remota. À guisa de exemplo, e sem caráter limitativo, a Figura 1 ilustra programas aplicativos remotos 185 à medida em que estão presentes no dispositivo de memória 181. Será avaliado que as conexões de rede mostradas são exemplificativas e outros meios de estabelecer um link de comunicação entre os computadores podem ser utilizados.

MODELO E ARQUITETURA DE FILTRO DE SISTEMA DE ARQUIVO

GERENCIADO

[0028] A presente invenção é geralmente dirigida em direção a um modelo e arquitetura de filtro de sistema de arquivo que pretende melhorar o manipulamento l/O de sistema de arquivo através de filtros, incluindo facilitar a interoperabilidade entre diversos produtos relacionados ao sistema de arquivo. Nota-se que o modelo é geralmente descrito no presente documento com referência aos acionadores de filtro que operam entre o gerenciador l/O e um sistema de arquivo de base, que pode ser um sistema de arquivo local ou remoto, e não descrito com referência a outros acionadores, incluindo acionadores de filtro que operam entre o sistema de arquivo e o acionador ou acionadores de armazenamento (tal como FtDisk ou DMIO).

[0029] Conforme usado no presente documento, acionadores de filtro “legados” são aqueles que manipulam pacotes de pedidos l/O (IRPs) de maneira tradicional em vez de através do modelo novo, que utiliza retribuição de chamada para acionadores de filtro registrados como descrito abaixo. Como espera-se, acionadores de filtro legados serão defasados com o tempo, os acionadores de filtro que irão agir de acordo com o novo registro e modelo de retribuição de chamada serão referidos no presente documento simplesmente como "acionadores de filtro”.

[0030] Um dos principais aspectos do novo modelo de filtro é dirigido à eliminação da l/O complexa, tradicional que passa do filtro legado para filtro legado através de um modelo de pilha, e substituir aquele modelo por um modelo de retribuição de chamada gerenciada, no qual IRPs, trajetórias de l/O, retribuições de chamadas de gerenciador de memória e assim por diante são transformados por um gerenciador de filtro em retribuições de chamadas que proporcionam dados de retribuição de chamada em um formato definido dentro dos filtros. Os filtros não chamam outros filtros, nem passam diretamente controle para outros filtros, porém de preferência manipulam os dados de retribuição de chamada como desejado, e retornam a um estado em resposta à retribuição de chamada, como descrito abaixo. Uma vez que os filtros não têm mais de lidar com IRPs e similares, muita da complexidade de manejamento l/O é removida dos filtros e construídas dentro de um gerenciador de filtro simples que elimina muitos dos problemas causados por diversos filtros. Por exemplo, IRPs geralmente contêm informações complexas, implícitas que acionadores de filtro legados encontravam tradicionalmente dificuldade em lidar com a presente invenção elimina este problema ao possuir o gerenciador de filtro que lida com informações implícitas, e passa somente contexto explícito para os filtros. O modelo de retribuição de chamada possui adicionalmente a vantagem de resolver o estouro da capacidade da pilha e fechar as saídas que surgem devido aos envios de IRP encadeados.

[0031] A Figura 2 representa uma implementação exemplificativa 200 do novo modelo. Uma vantagem da implementação representada na Figura 2 é que aplicações existentes, componentes de sistema operacional e sistemas de arquivo não precisam ser modificados de maneira alguma para implementar o novo modelo. Por exemplo, em um sistema operacional baseado em Windows®, um aplicativo 202 irá continuar a fazer pedidos de sistema de arquivo (por exemplo, através de função/método de chamadas) através de uma camada API 204 até um gerenciador l/O 206. Como se sabe, o gerenciador l/O 206 gera um IRP ou outro tipo de l/O ,e envia a l/O para o topo da pilha de aciona-dor de filtro (legado) 208. Como descrito abaixo, um dos componentes na pilha 208 é um gerenciador de filtro 212.

[0032] Em geral, o gerenciador de filtro 212 transforma a l/O, se for um IRP, l/O rápida, retribuição de chamada de Filtro FS ou similar em uma estrutura uniforme conhecida como dados de retribuição de chamada.Uma estrutura de dados de retribuição de chamada adequa- da é descrita abaixo. O gerenciador de filtro 212 atravessa então uma lista de acionadores de filtro registrados (por exemplo, cinco acionado-res de filtro 282A-282E como mostrado na Figura 2, embora possam ser qualquer número real de tais acionadores), e para cada acionador de filtro, pode solicitar um envio registrado para a l/O. De forma significativa, no modelo da presente invenção, os filtros não recebem e/ou manejam IRPs porém em vez de instruir essencialmente o gerenciador de filtro 212 sobre o que fazer com o pedido de l/O.

[0033] Como também representado na Figura 2, acionadores de filtro legados 210 podem continuar sendo sustentados nesta implementação, tal como ao colocá-los no topo da pilha 210. Nota-se entretanto que é possível ordená-los em outras ordens com relação a outros componentes de pilha. Por exemplo, uma vez que os acionadores de filtro legados são dispostos para manejar IRPs, não retribuições de chamadas, o código de gerenciamento especial pode envolver tal um filtro legado para gerar um IRP a partir de dados de retribuição de chamada para passar para o mesmo e receber o IRP (possivelmente modificado) a partir do mesmo e convertê-lo de volta a uma resposta de estado. Desta maneira, um filtro legado pode ser inserido e isolado dentro do modelo de retribuição de chamada. Em qualquer evento, filtros legados podem continuar sendo usados no novo modelo.

[0034] Para resumir a implementação mostrada na Figura 2, o gerenciador de filtro de sistema de arquivo 212 é empregado no novo modelo, e colocado dentro da pilha de acionador de filtro 208 como se fosse um acionador de filtro legado, de modo que este possa receber e processar IRPs. Nota-se que isto permite que o gerenciador de filtro funcione simplesmente em um sistema l/O existente, entretanto pode ser avaliado que um modelo equivalente (por exemplo, sem filtros legados superiores) pode ser proporcionado no qual uma gerenciador l/O atualizado passa dados de l/O para um gerenciador de filtro em algo senão uma estrutura de dados IRP. Por exemplo, quando o gerenciador l/O gera um IRP, o gerenciador de filtro gera uma estrutura de dados de retribuição de chamada a partir do IRP, e desta maneira o mesmo pode ser mais eficiente para o gerenciador 1/0 gerar diretamente a estrutura de dados de retribuição de chamada. Nota-se que algo senão um IRP já é proporcionado em sistemas existentes para 1/0 rápida, retribuições de chamadas de gerenciador de memória e assim por diante, que para desempenho mais rápido são baseados em retribuição de chamada em vez de baseados em pacote, para algumas tarefas 1/0 comuns tais como ler/gravar/controles de dispositivo 1/0. Ademais, nota-se que em sistemas existentes, 1/0 rápida é ainda passada através da pilha (ou seja, encadeadas, e não é desta maneira como o modelo baseado na retribuição de chamada da presente invenção. Para propósitos de simplicidade, a presente descrição irá usar primeiramente o exemplo de um IRP, exceto onde de outra maneira observados.

[0035] Em uma implementação, acionadores de filtro compreendem objetos ou similares que, quando instanciados, tipicamente durante seus procedimentos de inicialização de acionador, registram com um mecanismo de registro no gerenciador de filtro 212. Para eficiência, os acionadores de filtro irão tipicamente somente registrar para pedidos de sistema de arquivo nos quais estes podem estar interessados em processar. Para esse fim, como parte do registro, cada acionador de filtro notifica o gerenciador de filtro para tipos de pedidos l/O em que está interessado (por exemplo, criar, ler, gravar, fechar e assim por diante). Por exemplo, um acionador de filtro de criptografia pode registrar para ler e gravar IRPs, porém não para outros onde os dados não precisam ser cifrados ou decifrados. Semelhantemente, um filtro de cota pode estar interessado somente em criar arquivo e gravar arquivo. Como resultado, o modelo é mais eficiente que um modelo de filtro empilhado, devido aos acionadores de filtro somente observarem a l/O para qual estes registraram.

[0036] Para permitir a anexação nos volumes, o modelo da presente invenção define o conceito de uma “instância” de um acionador de filtro (e também um contexto de volume como descrito abaixo). Mais particularmente, acionadores de filtro que desejam anexar-se a um volume são notificados através de uma instância de notificação de configuração quando um novo modelo é montado. Uma notificação similar é proporcionada para volumes que já foram montados antes de um acionador de filtro ser carregado. Os acionadores de filtro pode então optar por anexar-se nos volumes através de registro, descrito abaixo, e nesse caso, um objeto exemplificativo é usado para representar a instância da anexação. Os acionadores de filtro são semelhantemente notificado quando um volume desmonta, isto é através de um uma notificação destacada exemplificativa. O presente modelo também permite que os acionadores de filtro destaquem-se de forma dinâmica de um volume montado.

[0037] Um acionador de filtro pode ser associado a uma altitude que indica onde na ordem de retribuição de chamada o acionador está localizado, tal como geralmente descrito no Pedido de Patente US 09/768.098 intitulada “Method and System for Deterministic Ordering of Software Modules”. Ademais, como representado na Figura 3, acionadores de filtro podem anexar-se muitas vezes ao mesmo volume, criando uma instância para cada anexação, (embora para fazer isso, que cada instância para o mesmo volume esteja necessariamente em uma altitude diferente, seja através de um número de ordem ou através de algum mecanismo de cancelamento).

[0038] A Figura 3 mostra um exemplo de filtro que possui diversas instâncias. Na Figura 3, um filtro A, por exemplo, um filtro de “monitoramento de atividade de sistema de arquivo”, monitora a l/O de arqui- vo, e possui duas instâncias, filtro A e filtro A’. Desta maneira, um produto de monitoramento de atividade de arquivo é capaz de observar (através do filtro A) a l/O entrando em um filtro B (por exemplo, antivírus) intermediário, bem como observa (através do filtro A’) a 1/0 que passa eventualmente através do filtro intermediário sobre a sua trajetória em direção ao sistema de arquivo. Por exemplo, o produto de monitoramento de atividade de arquivo pode incluir um programa de modo de usuário (não mostrado separadamente) que tanto o filtro A como filtro A’ apresenta, através de mensagens como descrito abaixo.

[0039] Desta maneira, instâncias de acionador de filtro por volume podem ser associadas a uma altitude que determine onde cada instância está localizada para aquele volume. As altitudes podem ser pré-designados para uma dada instância de filtro, tal como no Pedido de Patente US 09/768.098, e/ou um mecanismo sinalizador ou similar (descrito abaixo) pode ser usado para obter uma altitude apropriada para um filtro. Por exemplo, um filtro anti-vírus não deve ser permitido para anexar-se entre um filtro de criptografia e o sistema de arquivo de filtro, uma vez que o mesmo precisar observar os dados como são,antes da criptografia. Os sinalizadores podem indicar se um filtro examina dados (por exemplo, um filtro anti-vírus), modifica dados, (por exemplo, um filtro de criptografia), e assim por diante, a partir do qual uma altitude pode ser derivada. Desta maneira, a ordem de retribuição de chamada não é baseada na ordem na qual os acionadores são carregados, porém de preferência sobre algumas bases lógicas predeterminadas.

[0040] De acordo com um aspecto da presente invenção, os acionadores de filtro registram dois tipos de retribuições de chamadas, isto é pré-retribuições de chamadas e pós-retribuições de chamadas. A pré-retribuição de chamada é chamada no percurso até a l/O, ou seja, em direção ao sistema de arquivo, enquanto a pós-retribuição de cha- mada é chamada durante a terminação da l/O, no percurso de volta do sistema de arquivo em direção ao gerenciador 1/0.

[0041] Por eficiência, para rastrear quais acionadores de filtro foram registrados para quais tipos de retribuições de chamadas e desse modo determina de forma eficiente quais acionadores de filtro chamar quando l/O (por exemplo, um IRP) é recebida, o gerenciador de filtro 212 mantém uma ou mais estruturas de dados por volume. Por exemplo, como representado na Figura 4, quando uma instância de filtro registra em um mecanismo de registro 402 (por exemplo, ao chamar uma função) no gerenciador de filtro 212, o mecanismo de registro determina, através de um mecanismo de ordem 404 onde na ordem de pré-retribuição de chamada a instância de filtro pertence. O mecanismo de ordem 404 pode ser baseado em uma comparação simples de altitudes, ou pode incluir lógica que avalia os sinalizadores para determinar onde a instância de filtro se ajusta. Em qualquer evento, os nós de chamada por volume são mantidos, com as informações de registro do presente documento.

[0042] Como descrito abaixo, parte das informações enviadas ao gerenciador de filtro o registro compreende (por exemplo, em uma matriz) uma lista dos pedidos de sistema de arquivo para qual instância de filtro precisa de uma pré-retribuição de chamada. Estas informações são usadas para construir uma lista ordenada por volume 408 (por exemplo, volume c: ou 410 (por exemplo, volume d:) ou similar através da qual um mecanismo de retribuição de chamada 412 no gerenciador de filtro 212 pode determinar de forma eficiente a ordem para chamar cada instância. Por exemplo, como representado na Figura 4, se um pedido de leitura para um arquivo no volume c: for recebido, as instâncias de filtro interessadas em leitura (como indexados por um código maior IRP do IRP) podem ser rapidamente obtidas, por exemplo, instância de filtro A, instância de filtro B e instância de filtro A’ se- rão a ordem de pré-retribuição de chamada, como representado no exemplo na Figura 4. Nota-se que isto altamente eficiente, e também facilita registro dinâmico; registra a qualquer momento uma nova instância de filtro, o mecanismo de registro pode reconstruir as listas como apropriado.

[0043] Desta maneira, a ordem de pré-retribuição de chamada é determinada por tipo de pedido de l/O de arquivo, embora como descrito abaixo, o estado retornado por cada instância de filtro possa im-pactar as instâncias de filtro reais que recebem retribuições de chamadas, por exemplo, um filtro pode falhar uma retribuição de chamada. A pós-retribuição de chamada funciona essencialmente na ordem oposta, entretanto como descrito abaixo, um dos valores de estado que uma instância chamada pode retornar em uma pré-retribuição de chamada é bem sucedida sem uma pós-retribuição de chamada, em qual caso o gerenciador de filtro 212 irá pular a pós-retribuição de chamada para aquela instância.

[0044] Os valores de estado que uma instância de filtro pode retornar em resposta a uma retribuição de chamada que geralmente inclui sucesso sem retribuição de chamada, sucesso com retribuição de chamada, pendência, sincronizar, completar, e negar l/O rápida. Em uma implementação particular “FLT.PREOP.SUCCESS.NO. CALLBACK” continua a processar a passagem l/O, como o estado faz “FLT.PREOP.SUCCESS.WITH.CALLBACK”, que requer adicionalmente uma retribuição de chamada de terminação quando completa-se esta l/O. Um filtro pode também especificar FLT.PREOP.PENDING, que mantém a l/O até o filtro chamar posteriormente FltCompletePen-dedPreOperation(). FLT.PREOP.SYNCHRONIZE aguarda até a l/O ser concluída, e chama a pós-retribuição de chamada no contexto de en-cadeamento original. A sincronização de l/O é manejada pelo Gerenciador de Filtro. Nota-se que “pendência” e “sincronia” não pode ser retornada com l/O rápida. FLT.PREOP.COMPLETE completa a 1/0 tanto com sucesso como falha o código de estado (que é geral mente análogo a um Pedido Completo de 1/0 em um envio legado). FLT. PREOP.DISALLOW.FAST.IO é válido somente para 1/0 Rápida, e é geralmente equivalente a FALSO retorno em um envio legado.

[0045] Desta maneira, o modelo de acionador de filtro gerenciado permite que os acionadores de filtro controlem a trajetória de execução da l/O através de estado de retorno a partir de suas rotinas de pré-retribuição de chamada. Isto permite que os acionadores de filtro requeiram diferentes maneiras para que a l/O seja manejada, incluindo pendência, conclusão, passagem para os filtros inferiores, requerem uma pós-retribuição de chamada, requerem uma pós-retribuição de chamada “sincronizada” e assim por diante.

[0046] Como descrito no presente documento, instâncias de filtro registram para pós-retribuições de chamadas. Em resposta a uma pós-retribuição de chamada, uma instância de filtro (por exemplo, que retornaram previamente um estado de FLT.SUCCESS.WITH. CALLBACK) pode retornar um estado de FLT.POSTOP.FINISHED. PROCESSING.REQUIRED para continuar a terminação l/O, ou FLT. POSTOP.MORE.PROCESSING.REQUIRED para abandonar a terminação e completar posteriormente a l/O ao chamar uma função FltCompletePendedPostOperation(). Um filtro pode re-emitir uma l/O durante o seu processamento de pós-operação através da chamada de função FltReissueSynchonouslo() para re-analisar gramaticalmente os manipuladores. Um estado FLT.POSTOP.UNDO.CREATE é proporcionado para filtros que precisam bloquear aberturas de arquivo ao falhar o pedido de criação.

[0047] A terminação l/O é manejada pelo gerenciador de filtro 212 de maneira que garanta que os parâmetros vistos por uma instância de filtro em sua pré-retribuição de chamada sejam os mesmos em su- as pós-retribuições de chamadas. Nota-se que isto é uma melhora a respeito de modelo empilhado legado no qual filtros geralmente de parâmetros alterados, indicadores de armazenamento temporário e assim por diante, resultam em inúmeros problemas. Em geral, isto é executado como representado na Figura 5, onde o gerenciador de filtro mantém um nó de terminação para cada instância, (ou seja, pelo menos para aquelas instâncias que recebem retribuições de chamadas).

[0048] Em essência, para cada instância chamada em uma pré-retribuição de chamada que (através de seu estado) requereu uma retribuição de chamada, o gerenciador de filtro obtém uma captura instantânea (snapshot) dos parâmetros antes de cada pré-retribuição de chamada, armazenar a captura instantânea no nó de terminação, e empurra o nó de terminação para uma pilha 502. Para gerenciar os dados de pós-retribuição de chamada, para cada IRP, o gerenciador de filtro mantém um cabeçalho IRPCTRL 504, não observado pelo acionador de filtro, que rastreia informações que incluem o objeto de dispositivo, um indicador IRP, informações de nó que incluem o tamanho dos nós de terminação e sua instância correspondente, e assim por diante. Então, durante a pós-retribuição de chamada, o gerenciador de filtro se encaminha para trás, disparando cada nó de terminação da pilha 504 e colocando os dados de nó de terminação dentro dos dados de retribuição de chamada 506 para aquela instância, desse modo re-armazena seus parâmetros. Nota-se que a pilha pode ser copiada para outra pilha com um nó de terminação adicionado se uma instância de filtro registrar dinamicamente antes de ser retribuição de chamada na ordem; se registrada após a pré-retribuição de chamada já a ter passado na ordem de pré-retribuição de chamada para um dado IRP, aquela instância não seria chamada de volta.

[0049] Para eficiência, a pilha somente precisa ter um nó de terminação empurrada para a pilha quando uma instância de filtro está para receber uma retribuição de chamada, e quando uma instância de filtro faz uma alteração nos dados de retribuição de chamada, uma vez que de outra maneira o mesmo nó de terminação possa ser reutilizado. Uma instância de filtro é responsável por estabelecer um sinalizador de parâmetros “contaminados” quando o mesmo modifica os dados. Nota-se que se o mesmo não o fazer, suas alterações serão descartadas e não terão seus dados alterados flagrados, por meio do qual quaisquer alterações não serão notadas por outro acionador.

[0050] Ao retornar à Figura 2, após a última pós-retribuição de chamada ser feita, o gerenciador de filtro 212 reconverte (ordena) os dados de retribuição de chamada em um IRP e retorna o IRP até a pilha em direção ao gerenciador de l/O 206, através de quaisquer filtros legados superiores 210. Como pode ser avaliado, com este modelo de filtro gerenciado muitos desses inconvenientes do modelo legado são eliminados ou significantemente reduzidos.

[0051] Além das funções acima, o gerenciador de filtro também proporciona um rico conjunto de API que proporciona funções que os filtros normalmente precisam. Por exemplo, certos filtros precisam executar a l/O por conta própria, por exemplo, um filtro anti-vírus pode desejar ler um arquivo antes de ser aberto. Quando um acionador de filtro deseja iniciar sua própria operação l/O, primeiro ele chama FltAllocateCallbackData(). Esta função distribui e retorna uma estrutura FLT.CALLBACK.DATA , que o filtro então ocupa com quaisquer campos relativos. Nota-se que FltAllocateCallbackData() é essencialmente a substituição por chamar loAllocatelrp() no sistema legado. Quando o filtro está pronto para enviar o pedido l/O para quaisquer filtros restantes, filtros legados, e o sistema de filtro de base, o mesmo chama FltPerformSynchronouslo() ou FltPerformAsynchronouslo() (análogo a loCallDriver()), Através do valor predefinido, a l/O iniciada pelo filtro é enviada ao próximo filtro anexado para o dado volume, desviando de quaisquer filtros anexados acima do filtro que inicia a 1/0. É possível, entretanto, enviar 1/0 para qualquer dispositivo no sistema, como um filtro de gerenciamento de armazenamento hierárquico (HSM) que precisa fazê-lo.

[0052] Como outro exemplo, os filtros algumas vezes precisam criar um arquivo, e a função FltCreateFile() é proporcionada com um ponto de partida para iniciar a 1/0. A função retorna uma alça que pode ser usada com APIs de sistemas operacionais existentes que obtêm alças de arquivo, e permite criar sobre outras instâncias. A função sustenta cancelamento de acesso compartilhado. Ademais, o gerenciador de filtro garante que quaisquer retribuições de chamadas são somente observadas por filtros abaixo do filtro de requerimento, que inclui aqueles dinamicamente inseridos, que, como pode ser avaliado, impede retribuições de chamadas recursivas. Para esse fim, o gerenciador de filtro cria um arquivo com uma solicitação de estância, e usa essa solicitação para identificar o filtro de requerimento. Nota-se que aberturas de ponto de montagem são uma exceção, à medida em que estas precisam chegar ao topo da pilha de retribuição de chamada.

[0053] FltReadFile() permite 1/0 síncrona e assíncrona, com retribuição de chamada proporcionada por filtro que será emitida na terminação 1/0. FltWriteFile(), FltSetlnformationFile() e assim por diante possuem semântico similar. FltAllocateCallbackData() permite que 1/0 seja customizada, incluindo FltPerformSynchonouslo(), ou FltPerfor-mAsynchonouslo() que aceita uma retribuição de chamada de terminação 1/0.

[0054] O gerenciamento de contexto é outro exemplo onde APIs proporcionados por gerenciador de filtro são altamente vantajosos, como filtros geralmente precisam associar uma estrutura de contexto a cada alça de fluxo, fluxo, instância e volume. Por exemplo, os filtros utilizam os contextos para armazenar informações por alça /por flu- xo/por arquivo/por volume/por instância que são pesquisadas quando um filtro interrompe a l/O. Qualquer contexto ou contextos que um filtro tenha estabelecido sobre uma entidade será passado para o filtro quando este filtro o requerer, por exemplo, através de um API. A duração do contexto é gerenciada pelo gerenciador de filtro 212, e os filtros serão chamados novamente quando o contexto for eliminado devido ao objeto apropriado (tal como fluxo/arquivo/instância/volume) ser eliminado.

[0055] De acordo com outro aspecto da presente invenção, o gerenciador de filtro 212 proporciona suporte de contexto eficiente para armazenar dados de contexto(por exemplo, indicadores ou similar) para cada filtro no objeto apropriado, ou seja, para uma alça de fluxo, fluxo, arquivo, instância ou volume. Para esse fim, a presente invenção proporciona suporte de contexto, através de um conjunto de APIs que apresentam contexto para uma entidade, e desta maneira simplifica a associação de um contexto por filtro com aquela entidade. Os contextos podem ser estabelecidos e/ou restabelecidos a qualquer momento. A presente invenção também proporciona suporte de notificação para instâncias, através de um conjunto de retribuições de chamadas que configuram a notificação para uma instância.

[0056] Os tipos de entidades incluem instâncias, volumes (um volume de disco local, ou um compartilhamento de rede remota), fluxos (para sistemas de arquivo que sustentam diversos fluxos por arquivo), alças de fluxo por arquivo (objetos por arquivo), e arquivos (por exemplo, todos os fluxos de um arquivo). Com relação às instâncias, como descrito acima, quando um filtro anexa-se a um volume, uma instância é criada, e, como também descrito acima, podem haver mais de uma instância de um dado filtro para um dado volume, por exemplo, conectadas tanto acima como abaixo de outro filtro no mesmo volume. Cada instância pode possuir um contexto associado, por exemplo para apontar para um log privado para aquela instância. Um contexto de volume pode ser compartilhado entre as instâncias de filtro.

[0057] Para associar um contexto a um objeto, o filtro chama FltAllocateContext() que especifica o tipo de contexto (alça de fluxo, fluxo, arquivo, instância ou volume), o tamanho de contexto e se o contexto deve ser localizado a partir de memória agrupada paginada ou não paginada. Uma vez que o contexto é localizado e inicializado, o filtro associa o contexto ao objeto ao chamar a rotina apropriada: FltSetStreamHandleContext(), FltSetStreamContext(), FltSetFileCon-text(),FltSetlnstanceContext() ou FltSetVolumeContext().

[0058] Como representado na Figura 6, para melhorar de forma eficiente os instâncias de filtro associadas aos arquivos, fluxos e alças de fluxo, o gerenciador de filtro 212 anexa uma árvore (por exemplo, uma árvore de difusão) à estrutura de dados associada ao objeto de arquivo. Mais particularmente, o sistema operacional facilita a anexação do contexto arbitrário a um fluxo, e o gerenciador de filtro 212 utiliza este mecanismo para anexar uma lista de controle de fluxo 608 e uma árvore 610 ao FSTRL ADVANCED.FCB.HEADER 612, que é essencialmente sugerido pelo objeto de arquivo 614 através de seu contexto 616. Cada nó na árvore 610 representa uma instância de filtro que possui um contexto associado para este fluxo. Embora não mostrado separadamente, pode haver árvores paralelas, uma para memória pool paginada e uma para memória pool não paginada, como especificado pela instância de filtro para tipos diferentes de acesso que podem ser necessários.

[0059] Para uma dada alça de fluxo, cada nó na árvore é acessado por chaves, que incluem o objeto de arquivo como uma chave e a instância como outra. Nota-se que para fluxos, a chave de objeto de arquivo é NULA. Como representado na Figura 7, quando proporcionado com estas chaves, tal como através de dados em uma chamada de função para um mecanismo de contexto 412 dentro {ou associado com) o gerenciador de filtro 212, o nó apropriado na árvore 610 pode ser rapidamente localizado pela instância de acionador de filtro 702, e o contexto apropriado 704 (por exemplo, na forma de um indicador de contexto) retornado à instância de acionador de filtro de requerimento 702. Em parte a transversal é rápida porque geralmente náo há muitas instâncias de filtro em uma dada configuração.

[0060] Em uma implementação, um filtro pode receber uma notificação para uma instância: typedef PVOID PFLTCONTEXT;

NTSTATUS CPFLT.INSTANCE.SETUP.CALLBACK) ( IN CONST PFLT.RELATED.OBJECTS FitObjects, IN FLT.INSTANCE.SETUP.FLAGS Flags, IN DEVICE.TYPE VolumeDeviceType );

[0061] Se o contexto for necessário para uma instância particular, o mesmo pode estabelecê-la nesta retribuição de chamada. O contexto é um PVOID, e o sistema irá tratá-lo como completamente opaco, então um filtro pode usá-lo para armazenar um campo de sinalizado-res, um contador, um indicador, ou alguma coisa mais que for necessária. Se o filtro for capaz de inicializar de forma bem sucedida a sua retribuição de chamada exemplifícativa e desejar monitorar atividade sobre este volume, o mesmo deve retornar STATUS.SUCCESS, Se o filtro não quiser que esta instância seja criada sobre este volume, STATUS.FLT.DΟ.NOT.ATTACH deve ser retornado. As retribuições de chamadas de limpeza de notificação para instâncias são proporcionadas para sincronizar corretamente a desmontagem de instância à medida em que novas operações podem chegar ao volume, e incluírem InstanceQueryTeardown, I nstanceT eardownStart e InstanceTear- downComplete.

[0062] Um filtro que proporciona uma estrutura de contexto para alguma entidade irá ter seu ContextCleanupCalIback correspondente chamado. Em outras palavras, para evitar a perda de pool de memória, um filtro não precisa manter a trilha de quais contextos foram alocados, à medida em que o sistema irá cuidar de quando a limpeza deve ocorrer. Quando um contexto deve ser liberado, o sistema chama ContextCleanupCalIback do filtro. Durante esta retribuição de chamada, o filtro é responsável por não inicializar os conteúdos do contexto e ao retornar o sistema irá liberar a memória alocasada pela chamada FltAllocateContext() mais recente do filtro. As limpezas são adotadas para darem resultado; portanto estas não precisam ser um valor de retorno. O sistema também garante que as rotinas de limpezas de contexto serão chamadas em um IRQL baixo o suficiente de modo que a desocupação de agrupamentos seja feita de forma segura.

[0063] Um contexto de instância torna-se limpo quando o filtro é separado do volume. Um contexto de volume torna-se limpo após o volume ser desmontado, e após todos os arquivos, fluxos, e alças de fluxo para o volume serem limpos. Devido ao gerenciador de memória, gerenciador de cache, e detalhes de implementação de sistema de arquivo, o contexto de volume pode não ser limpo por um período relativamente longo após o volume ser desmontado [0064] Um contexto de arquivo torna-se limpo quando o sistema de arquivo libera a memória associada ao arquivo, que em um sistema de arquivo de fluxo múltiplo, será após a última alça de fluxo para o último fluxo para aquele arquivo ser liberado. Nota-se que devido ao gerenciador de memória do sistema operacional e gerenciador de cache poder continuar tendo referências a um ou mais fluxos no arquivo, o contexto de arquivo pode não ser limpo por um período relativamente longo após a última alça de usuário para o fluxo ser fechada. De forma similar, um contexto de fluxo torna-se limpo quando o sistema de arquivo libera a memória associada ao fluxo, que será após a última alça de fluxo para aquele fluxo ser liberado. Novamente, devido ao gerenciador de memória do sistema operacional e gerenciador de cache poder continuar tendo referência a um ou mais fluxos no arquivo, o contexto de fluxo pode não ser limpo por um período de tempo relativamente longo após a última alça de usuário para o fluxo ser fechada.

[0065] Um contexto de alça de fluxo torna-se limpo quando a última referência à alça de fluxo ser liberada. Isto pode ter como resultado da alça de usuário ser fechada, ou a última referência de gerenciador de memória ou gerenciador de cache ser liberada.

[0066] Um contexto pode ser estabelecido por um objeto se o objeto não possuir comumente um contexto, ou um contexto pode ser alterado. Um filtro pode limpar um contexto utilizando uma das seguintes rotinas, como apropriado: FltDeleteContext(), FltDeleteVolumeCon-text(), FltDeletelnstanceContext(), FltDeleteFileContext(), FltDeleteS-treamContext() e FltDeleteStreamHandleContext().

[0067] Um filtro geralmente irá solicitar algumas informações básicas sobre uma entidade para decidir se o mesmo está interessado nestas. Para um volume, este deve ser o sistema de arquivo, se o volume for local ou remoto, se o mesmo estiver sobre uma mídia removível, e assim por diante. Para um arquivo, este pode incluir o nome do arquivo, marcas de tempo, dimensão, extensão, e assim por diante. O sistema pode apresentar funções (por exemplo, FltGetFilelnforma-tion(),FltGetVolumelnformation()) para recuperar estas informações. O filtro pode também desejar chamar FltTagFile() para estabelecer um ponto de re-análise sobre um arquivo.

[0068] Ainda outro conjunto de APIs proporcionados pela arquitetura da presente invenção, são dirigidos para facilitar a comunicação entre as instâncias de filtro e código de modo de usuário. Mais particu- larmente, muitos filtros possuem um complemento de serviço de modo de usuário que é tipicamente o componente administrativo do produto, e os filtros precisam comunicar-se com o serviço. A presente arquitetura pode proporcionar APIs para estes produtos para usar para ambos modos de usuário iniciados bem como uma comunicação iniciada por kernel.

[0069] Por exemplo, para os filtros que comunicam-se com um componente de modo de usuário, uma biblioteca está disponível para aqueles aplicativos de modo de usuário. A biblioteca apresenta rotinas, que incluem rotinas para carregar e descarregar filtros, anexar e desa-nexar os filtros aos volumes, abrir canais de comunicação abertos para filtros a partir de modo de usuário e enviar/receber dados dos filtros, e perguntar ao sistema por informações sobre o estado atual do sistema. Por exemplo, um programa de modo de usuário pode perguntar quais filtros são atualmente carregados, quais instâncias existem em um dado volume ou um dado filtro, e assim por diante. Nota-se que a comunicação filtro-usuário é diferente de APIs de administração que são proporcionados que permitem enumeração de filtros/instâncias, des-carregar/carregar filtros e assim por diante, à medida em que APIs de comunicação filtro-usuário são para uso por filtros para fazerem sua própria comunicação privada.

[0070] Em resumo, o novo modelo de filtro proporciona uma maneira de gravar de forma confiável, eficiente, filtros de sistema de arquivo que permitem carregamento/descarregamento dinâmico, anexa-ção/desanexação dinâmica aos volumes, ordenamento flexível, e acesso a um rico conjunto de APIs que os filtros mais comumente necessários. Os seguintes proporcionam detalhes específicos para uma implementação exemplificativa que é baseada no sistema operacional Windows" NT/2000/XP.

IMPLEMENTAÇÃO EXEMPLIFICATIVA

[0071] A seguinte descreve algumas das operações iniciadas por filtro executadas através de chamadas de função, que incluem registro com o gerenciador de filtro;

[0072] Filtro declara retribuições de chamadas para l/O interessantes;

ΠΤΤΟΡΕ^ΑΊΊΟΝ J^Q|3ypj^p|^^a||backsnK { IRP.MJ.CREATE, 0, //Sinalizadores AvCreate, //pré-retribuição de chamadas AvCreateCompletion}, //pós-retribuição de chamadas { IRP.MJ.Write, 0, AvWrite, Av W ri teCo m pl eti o n}, }: [0073] Filtro declara uma estrutura de registro: const FLT.REGISTRATION FilterRegístratíon={ AvUnload, //Unload routine AvInstanceSetup, //Instance Setup AvinstanceQueryTeardown, AvinstanceTeardownStart, AvinstanceTeardownComplete, Callbacks, //operation callbacks };

[0074] Filtro registra com gerenciador de filtro: status= Flt Regi ste rF i I ter{ D ri ve rÕ bj ect, &FilterRegístration, &AvFÍIterHandle);

[0075] Filtro recebe pré-retribuíções de chamadas: FLT.PRE.OPERATION.CALLBACK.STATUS aVWrite{ IN OUT PFLT.CALLBACK.DATA Data, IN CONST PFLT.RELATEDOBJECTS FltObjects, OUT PVOID *CompletionContext );

[0076] Nesta implementação exemplificativa, os acionadores de filtro de sistema de arquivo compreende acionadores de modo kernel, e como tais são requeridos para exportar uma função chamada Drive-rEntryO, que é a primeira função solicitada quando o acionador é carregado. Quando carregado, os filtros chamam uma função para registrar FltRegisterFilterQ nomeado em seus DriverEntry(). FltRegisterFil-ter() toma como parâmetro uma estrutura FLT.REGISTRATION, que contém {entre outras coisas) configuração de instância e retribuições de chamadas desmontadas, uma lista de indicadores de função de retribuição de chamada de contexto, e uma lista de indicadores de retribuição de chamada para operações de sistema de arquivo. Nota-se que em muitos cenários nos quais um filtro deseja enganchar somente um número relativamente pequeno de operações, e está somente interessado em estabelecer contextos para poucos , se algum, objetos, esta lista pode ser muito curta.

[0077] Em uma implementação alternativa, pode haver um campo de sinalizadores no qual um filtro estabelece um ou mais sinalizadores atribuídos a filtro a partir dos quais uma altitude pode ser derivada. Por exemplo, um sinalizador pode ser estabelecido por um filtro que modifica dados, tal como para um filtro de criptografia ou compactação para notificar o sistema que o mesmo modifica dados na trajetória até e a partir do sistema de arquivo de base. Nesta implementação, qualquer filtro que rompa os dados de um usuário dentro de múltiplos fluxos de- vem também estabelecer este sinalizador. Os filtros podem também estabelecer um sinalizador para indicar que o filtro examina os dados, por exemplo, um filtro de vírus que necessita observar dados de texto sem formatação, descompactado podem estabelecer este sinalizador. Os sinalizadores estão também disponíveis para filtros que modificam as informações padrão (tal como marcas de tempo e datas), para filtros que examinam informações padrão, (por exemplo, para executar operações diferentes em um arquivo baseado em suas datas), para filtros que redirecionam uma criação para um arquivo/fluxo de um nome diferente (por exemplo, um link simbólico/SIS tipo filtro), e para filtros que contam com nomes de arquivo, (tal como um filtro de vírus que examina arquivos .EXE e .DOC).

[0078] Como descrito acima, estes sinalizadores podem ser usados para auxiliar o sistema a conectar filtros ao volume na ordem correta. Por exemplo, não deve se permitir que um filtro anti-vírus conecte-se entre um filtro de criptografia e o sistema de arquivo de base, uma vez que o filtro anti-vírus necessita observar os dados como são, antes da criptografia. Para evitar isso, o modelo não permite que o filtro que possui um sinalizador que indica que o filtro examina conjunto sinalizador de dados conecte-se acima do filtro com um conjunto sinalizador que indica que o filtro modifica os dados. Ademais, certas combinações desses sinalizadores pode, ser usadas para impedir a anexação de um filtro, por exemplo, se dois sinalizadores de conjunto de filtro que indicam que cada filtro tanto examina como modifica os dados, não há ordem nos quais que ambos filtros possam ser anexados de forma segura ao mesmo volume.

[0079] O seguinte estabelece adiante uma ordem lógica para tipos de acionadores de sistema de arquivo: Monitoramento de Atividade (escuta de arquivo etc.) Recuperação Anti-vírus Replicação Cópia de segurança contínua Filtro de conteúdo Gerenciamento de cota Sistema de arquivo cluster HSM (gerenciamento de armazenamento hierárquico de terceiros) Compactação Criptografia Gerenciamento de Cota Física Reabertura de cópia de segurança de Arquivo (captura instantânea de arquivos abertos) Otimizador de Segurança Proteção Contra Cópia Sistema Infraestrutura de Arquivo (gerenciador de filtro) [0080] Como descrito acima, dados de retribuição de chamada são uma unidade de representação l/O, um tanto análogos a um IRP, para o propósito de representar as informações necessárias que descrevem a operação até o acionador de filtro. Os dados de retribuição de chamada contêm parâmetros normalizados, especializados nos usos do filtro de sistema de arquivo, e existem para l/O Rápida, chamadas de IRP 8 FsFiltro. A seção de parâmetro alterável pode ser modificada (ou seja, contaminados) pelo acionador, e a seção de parâmetro é estimada pelo gerenciador de filtro para filtro através da operação de disparo de pilha de nó de terminação, descrita acima.

[0081] O seguinte é uma estrutura de dados de retribuição de chamada exemplificativa: typedef struct.FLT.CALLBACK,DATA { FLT.CALLBACK.DATAFLAGS Flags; // // Encadeamento que iniciou esta operação. // PETHREAD Thread; PFLTJOPARAMETER.BLOCK lopb; IO.STATUSBLOCK loStatus; // outros dados:re-analisar armazenamento temporário de dados, enlaces de // fila, área de contexto para filtros } F LT.C AL L B AC KL DATA, PFLT.CALLBACK.DATA;

[0082] O seguinte é um bloco de parâmetro l/Õ exemplifícativo: type def structFLT.IOPARAMETER.BLOCK { UCHAR MajorFunction; UCHAR MinorFunction; PFile.OBJECT TargetFileObject; PFLT.INSTANCE Targetlnstance; // // parâmetros normalizados para a operação // FLTPARAMETERS Parameters; } FLTJOPARAMETER.BLOCK. *PFLTJOPARAMETER.BLOCK;

[0083] Retribuições de chamadas de pré-operação possuem a mesma assinatura: FLT.PREOP.CALLBACKLSTÃTUS (*PFLT.PRE_OPERATION.CALLBACK) { IN OUT PFLT.RELATED.DATA Data, IN CONST PFLT.RELATED.OBJECTS Fltobjects, OUT PVOID *CompletionContext);

[0084] Como descrito acima, as retribuições de chamadas de pré-operação podem retornar do seguintes estados (e outros) para FLT. PREOP.CALLBACK.STATUS: ._........._..__..suce_- dida e o filtro deseja ter a sua retribuição de chamada de pós-operação chamada FLT.PREOP.SUCCESS.NO.CALLBACK- a operação foi bem sucedida, retribuição de chamada chamada FLT.PREOP.PENDING- o acíonador de filtro irá completar a operação (ao chamar FltCompletePendedPreoperation()) alguma vez no futuro FLT.PREOP.COMPLETE- o filtro concluiu a operação. Uma operação pode falhar ao estabelecer um estado de erro e retornar a este estado de retribuição de chamada. FLT.PREOP.SYNCHRONIZE- o filtro deseja o processamento de terminação executado no mesmo contexto de encadeamento em que a retribuição de chamada de pré-operação foi executada; o encadeamento que origina esta l/O não será retornado até esta l/O ser concluída. FLTPREOP.DISALLOW.FASTIO- o filtro deseja negar a dada operação FastIO; Isto indica que o percurso de l/O rápido é negado, porém o gerenciador l/O irá utilizar o percurso IRP usual para concluir a l/O.

[0085] As retribuições de chamadas de pós-operação possuem a mesma assinatura: FLTPOSTOP.CALLBACK.STATUS (*PFLT.POST.OPERATION.CALLBACK) ( IN OUT PFLT.CALLBACK.DATA Data, IN CONST PFLT.RELATED.OBJECTS FltObjects, IN PVOID CompletionContext, IN FLTPOST.OPERATION.FLAGS Flags);

[0086] Õs sinalizadores podem incluir: FLTFL POST OPERATION7DRAINÍNG-..Se estabelecida, a dada ins- tância está sendo desanexada e esta rotina de pós-operação está sendo chamada para processamento de limpeza.

Ifltpostop FLT.POSTOP FINISHED.PROCESSING- o filtro concluiu o processa-mento da operação FLT.POSTOP.MORE.PROCESSING.REQUIRED- o acionador de filtro irá concluir a operação (ao chamar FltCompletePendedPostOperation) alguma vez no futuro FLT.POSTOP.UNDO.CREATE- o filtro deseja desfazer a dada operação de criação [0087] O filtro irá receber uma retribuição de chamada de terminação por retribuição de chamada de pré-operação. Por exemplo, se a memória for alocada na pré-retribuição de chamada, um filtro pode garantir que será dada uma chance de liberá-la na retribuição de chamada de terminação, e que a retribuição de chamada de terminação não será chamada mais de uma vez para motivar o filtro a liberar a memória mais de uma vez.

[0088] As operações para que as pré-retribuições de chamadas e pós-retribuições de chamadas possam ser proporcionadas incluem os códigos IRP.MJ. existentes a partir de códigos IRP.MJ.CREATE até IRP.MJ.PNP, IRP.MJ criados para representar operações IRP rápidas para que não haja IRP equivalente, e códigos IRP.MJ criados para re- presentar operações de filtro FS. Se as versões de sistema operacional futuras adicionarem novos códigos IRP.MJ.os filtros existentes não serão afetados, e não irão receber quaisquer retribuições de chamadas para rotinas IRP.MJ. que não existem quando o filtro foi compilado. Se um filtro registrar com um código IRP.MJ. que o sistema operacional não reconhece, FltRegisterFilter() irá retornar a um estado de sucesso especial, e somente chama as retribuições de chamadas para funções que existirem naquela versão. Se um filtro não desejar continuar a executar se uma ou mais retribuições de chamadas não forem proporcionadas, o filtro pode chamar FltUnregisterFilter().

[0089] Nota-se que as retribuições de chamadas para IRP.MJ. READ e IRP.MJ.WRITE serão solicitadas para IRP baseado em l/O e para l/O rápida. A pré-chamada para IRP.MJ.CREATE não será passada contextos para o arquivo ou fluxo, como ainda não determinado no tempo de pré-criação que o arquivo ou fluxo (se algum) será criado. A pós-chamada para IRP.MJ.CLOSE não será passada qualquer contextos, à medida em que as estruturas de sistema interno com quais estas estão associadas são liberadas antes da rotina pós-fechada ser chamada. As pré-retribuições de chamadas para IRP.MJ.CLEANUP e IRP.MJ.CLOSE devem dar resultado e retornar a FLT.PREOP. SUCCESS.WITH.CALLBACK ou FLT.PREOP.SUCCESSNO. CALLBACK.

[0090] As retribuições de chamadas de pós operação possuem o potencial para serem chamadas em nível DPC, e portanto estas não devem esperar por recursos ou (mutexes), nem devem chamar qualquer função que deva esperar. Nota-se que as rotinas tais como FltSetFileContext() adquirem recursos e desta maneira não devem ser chamadas a partir de retribuições de chamadas de pós-operação.

[0091] Como descrito acima, as pós-retribuições de chamadas tanto FLT.POSTOP.STATUS.SUCCESS como FLT.POSTOP.MORE. PROCESSING.REQUIRED. As pós-retribuições de chamadas pode falhar ao definir um código de erro no loStatus, e em geral a regra que é a responsabilidade do filtro para desfazer o que alguma vez tenha ocorrido.

[0092] Ademais, para registrar de forma dinâmica as instâncias de filtro, as instâncias de filtro podem ser dinamicamente desanexadas, pelas quais tal instância de filtro não mais será chamada para quaisquer operações naquele volume. Descarregar um filtro significa essencialmente que o seu código não está mais em memória. Isto será mais freqüentemente feito na hora de desligar o sistema e quando uma nova versão de um filtro está sendo instalada sem desligar o sistema. Nota-se que uma instância de filtro pode ser desanexada mesmo quando há l/O importante. Neste caso, a rotina ou rotinas de terminação do filtro serão chamadas por quaisquer operações l/O importantes com o conjunto sinalizador FLTFL.POST.OPERATION.DRAINING.. O filtro não receberá retribuições de chamadas de terminação quando realmente concluir aquelas operações l/O .Quando uma instância de filtro é desanexada, o sistema irá chamar rotinas para liberarem o contexto do filtro, para contextos importantes para arquivos, fluxos, e objetos de arquivo de fluxo associados àquela instância.

[0093] Como pode ser visto a partir da descrição detalhada anterior, foi proporcionada uma arquitetura de acionador de filtro gerenciado que manipula muitos dos requerimentos de manejamento l/O, desse modo facilita acionadores de filtro mais simples e mais confiáveis. Os acionadores podem registrar de forma seletiva para somente a l/O na qual estes estão interessados, melhorando a eficiência. A carga e descarga dinâmica, anexação e desanexação são concluídas. Outros benefícios incluem gerenciamento de contexto, que inclui sobre sistemas de arquivo com capacidades de multi-fluxo. O método e sistema proporciona dessa maneira vantagens e benefícios significativos necessá- rios em computação contemporânea.

[0094] Ao mesmo tempo em que a invenção é suscetível a diversas modificações e construções alternativas, certas modalidades ilustradas do presente documento são mostradas nos desenhos e foram descritas acima em detalhe. Deve-se entender, entretanto, que não há intenção de limitar a invenção às formas específicas mostradas, porém em contrapartida, a invenção serve para cobrir todas as modificações, construções alternativas e equivalentes que estão dentro do espírito e escopo da invenção.

REIVINDICAÇÕES

Claims (47)

1. Método em um ambiente de computação caracterizado pelo fato de que compreende as etapas de: registrar cada um de uma pluralidade de acionadores de filtro (282) para pelo menos um de um pré-chamada de retorno e um pós-chamada de retorno na forma de um pedido de sistema de arquivo l/O, uma chamada de retorno sendo uma estrutura de dados contendo dados de chamada de retorno para passar dados que correspondem ao pedido de l/O para um acionador de filtro, uma pré- chamada de retorno sendo uma chamada de retorno para passar dados de chamada de retorno para um acionador de filtro a ser aplicado na forma do pedido l/O para o sistema de arquivos, e uma pós-chamada de retorno sendo uma chamada de retorno para passar dados de chamada de retorno para um filtro a ser aplicado sobre o caminho do pedido l/O de volta a partir do sistema de arquivos para um gerenciador de l/O; receber um pedido de sistema de arquivos l/O direcionado para um sistema de arquivos (276); converter os dados no pedido do sistema de arquivos l/O em dados de chamada de retorno para passar para um primeiro acionador de filtro, os dados de chamada de retorno fornecendo dados em um formato bem definido que difere do pedido de l/O; chamar um primeiro acionador de filtro com um pré-chamada de retorno, em que o primeiro acionador de filtro é determinado com base em uma ordem de pré-chamada de retorno de uma pluralidade de acionadores de filtro (282); receber um valor de status a partir do primeiro acionador de filtro em resposta à pré-chamada de retorno, em que o valor do status indica tanto um sucesso quanto um pedido para não ser chamado de volta com uma pós-chamada de retorno, ou o sucesso e um pedido para ser chamado de volta com um post-chamada de retorno; chamar pelo menos um outro acionador de filtro com outra pré-chamada de retorno, incluindo chamar um último acionador de filtro com base na ordem de pré-chamada de retorno, incluindo passar dados que correspondem ao pedido de l/O para o último acionador de filtro, reconverter os dados de chamada de retorno recebidos a partir do último acionador de filtro em um pedido de sistema de arquivos reconvertidos 1/0; passar o pedido de sistema de arquivos reconvertidos 1/0 para o sistema de arquivos; se o valor de status indica sucesso e um pedido para não ser chamado de volta com uma pós-chamada de retorno, retornar dados correspondentes ao pedido de sistema de arquivos 1/0 para um originador do pedido de sistema de arquivos 1/0 sem chamar o primeiro acionador de filtro com uma pós-chamada de retorno; e se o valor do status indica sucesso a um pedido para ser chamado de volta com uma pós-chamada de retorno, chamar com uma pós-chamada de retorno o primeiro acionador de filtro.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende receber um pedido de registo do acionador de filtro a partir do primeiro filtro.

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que ainda compreende registrar o primeiro acionador de filtro em resposta ao pedido, incluindo ordenar o primeiro acionador de filtro para a ordem de pré-chamada de retorno no que diz respeito a cada outro acionador de filtro na ordem de pré-chamada de retorno.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que registrar o primeiro acionador de filtro compreende registrar uma instância do acionador de filtro para um volume de sistema de arquivo específico.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a instância do acionador de filtro registrado para um volume de sistema de arquivos específico compreende um mesmo tipo de acionador de filtro como outra instância do acionador de filtro registrado para esse volume.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro acionador de filtro registra pelo menos um tipo de pedidos de arquivo l/O.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que ainda compreende construir uma lista ordenada para cada tipo de pedido de l/O, a lista ordenada indicando uma ordenação de cada acionador de filtro que está registrado para processar esse tipo de pedido de l/O.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende, depois de passar o pedido de sistema de arquivo de l/O para o sistema de arquivos, chamar pelo menos um dos primeiros ou dos últimos acionadores de filtro do sistema de arquivos com uma pós-chamada de retorno, em que uma pós-chamada de retorno é uma chamada de retorno para passar os dados da chamada de retorno para um filtro a ser aplicado sobre o caminho do pedido de l/O de volta a partir do sistema de arquivos para um gerenciador de l/O.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende receber um valor de status indicativo de um estado acabado em resposta à pós-chamada de retorno para o primeiro acionador de filtro.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende recebe um valor de status indicando que o processamento adicional é necessário em resposta à pós-chamada de retorno para o primeiro acionador de filtro, e receber uma chamada a partir do primeiro acionador de filtro indicando que o processamento adicional foi completada.

11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a ordem de pré-chamada de retorno baseia-se uma altitude para cada acionador de filtro, e ainda compreende derivar uma altitude para o primeiro acionador de filtro com base na informação fornecida pelo primeiro acionador de filtro.

12. Método, de acordo com a reivindicação 11, caracterizado pelo fato de que ainda compreende receber um pedido de registo a partir do primeiro acionador de filtro, o pedido incluindo as informações fornecidas pelo primeiro acionador de filtro a partir do qual a altitude é derivada.

13. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende chamar com uma pós-chamada de retorno o primeiro acionador de filtro de acordo com uma ordem de pós-chamada de retorno da pluralidade de acionadores de filtro (282).

14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que ainda compreende armazenar os parâmetros de dados de uma pré-chamada de retorno para o primeiro acionador de filtro, e recuperar e fornecer pelo menos parte dos parâmetros armazenados nos dados de chamada de retorno de uma pós-chamada de retorno para o primeiro acionador de filtro.

15. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que armazenar os parâmetros de dados de uma pré-chamada de retorno para o primeiro acionador de filtro compreende armazenar os parâmetros em um nó de conclusão e empurrar o nó de conclusão para uma pilha de nó de conclusão.

16. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende determinar se o último acio- nador de filtro solicitou uma pós-chamada de retorno e, em caso afirmativo, a) armazenar os parâmetros de dados de uma pré-chamada de retorno para o último acionador de filtro e b) chamar o último acio-nador de filtro com uma pós-chamada de retorno, incluindo recuperar e fornecer pelo menos parte dos parâmetros armazenados nos dados de chamada de retorno de uma pós-chamada de retorno para o último acionador de filtro.

17. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que armazenar os parâmetros de dados de uma pré-chamada de retorno para o último acionador de filtro compreende determinar se o último filtro modificou outros parâmetros armazenados para uma pós-chamada de retorno para um outro acionador de filtro, e se não, usar os outros parâmetros armazenados como parâmetros armazenados para o último acionador de filtro e o outro acionador de filtro.

18. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende receber um pedido para retornar dados de contexto para o primeiro acionador de filtro, e retornar dados correspondentes ao contexto em resposta ao pedido, em que os dados de contexto correspondem a um de um conjunto que compreende: um manuseio de fluxo, um fluxo, um arquivo, um volume e uma instância.

19. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende retornar dados de contexto para o primeiro acionador de filtro, em que os dados de contexto correspondem a um de um conjunto que compreende: um manuseio de fluxo, um fluxo, um arquivo, um volume e uma instância.

20. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que os dados de contexto são retornados em resposta a um pedido.

21. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que os dados de contexto são retornados como parte de uma notificação.

22. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que ainda compreende manter uma árvore, e pesquisar a árvore para os dados de contexto.

23. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que ainda compreende receber uma chave, e pesquisar a chave com base na chave.

24. Método, de acordo com a reivindicação 23, caracterizado pelo fato de que a chave compreende um identificador de objeto de arquivo e um identificador de instância.

25. Método, de acordo com a reivindicação 23, caracterizado pelo fato de que a chave compreende um identificador de instância.

26. Método, de acordo com a reivindicação 22, caracterizado pelo fato de que a árvore inclui nós, cada nó correspondendo a uma instância.

27. Método, de acordo com a reivindicação 22, caracterizado pelo fato de que a árvore corresponde a um fluxo.

28. Método, de acordo com a reivindicação 27, caracterizado pelo fato de que a árvore é adicionada a outros dados de fluxo mantidos pelo sistema de arquivos.

29. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que receber um primeiro pedido de sistema de arquivo de l/O dirigido para o sistema de arquivo compreende receber um pacote de pedido de l/O a partir de um filtro de legado.

30. Método, de acordo com a reivindicação 29, caracterizado pelo fato de que ainda compreende retornar um pacote de pedido de l/O para o filtro de legado.

31. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o pedido de sistema de arquivo de l/O dirigido para o sistema de arquivo compreende um pacote de pedido de l/O recebido a partir de uma entidade, e ainda compreendendo retornar um pacote de pedido de l/O correspondente para a entidade.

32. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende receber outro pedido de l/O iniciado no primeiro acionador de filtro, e enviar o outro pedido de l/O para o sistema de arquivos, incluindo o pré-chamar pelo menos um outro acionador de filtro com os dados de chamada de retorno correspondendo ao pedido de l/O.

33. Método, de acordo com a reivindicação 32, caracterizado pelo fato de que o outro pedido de l/O compreende um pedido para criar um arquivo, e ainda compreende criar um arquivo com uma dica que identifica o primeiro acionador de filtro como tendo iniciado o pedido.

34. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: registrar uma pluralidade de acionadores de filtro em uma ordem de chamada de retorno, a pluralidade incluindo um acionador de filtro intermédio que está abaixo de um acionador de filtro superior e está acima de um acionador de filtro inferior, em que a etapa de receber um pedido de sistema de arquivo dirigido de l/O é iniciado no acionador de filtro intermediário; manter as informações que indicam que o pedido de l/O foi iniciado pelo acionador de filtro intermediário; enviar o pedido de l/O para o sistema de arquivos; receber dados de status a partir do sistema de arquivos correspondendo ao pedido de l/O; retornar os dados de status para o acionador de filtro inter- mediário que iniciou o pedido de l/O; e acessar a informação que indica que o pedido de 1/0 foi iniciado pelo acionador de filtro intermédio de modo a não deixar passar os dados de status para o acionador de filtro superior.

35. Método, de acordo com a reivindicação 34, caracterizado pelo fato de que ainda compreende chamar o acionador de filtro inferior com uma pré-chamada de retorno contendo dados de chamada de retorno que corresponde ao pedido de 1/0.

36. Método, de acordo com a reivindicação 35, caracterizado pelo fato de que ainda compreende chamar o acionador de filtro inferior com uma pós-chamada de retorno contendo os dados de chamada de retorno correspondendo aos dados de status.

37. Método, de acordo com a reivindicação 34, caracterizado pelo fato de que o pedido de 1/0 compreende um pedido para criar um arquivo, e em que manter a informação compreende solicitar a criação do arquivo com uma dica que identifica o acionador de filtro intermediário como tendo iniciado o pedido.

38. Método, de acordo com a reivindicação 37, caracterizado pelo fato de que ainda compreende receber uma solicitação escrita iniciada no acionador de filtro intermediário correspondente ao arquivo criado, enviar a solicitação escrita para o sistema de arquivos, receber outro conjunto de dados de status do sistema de arquivos correspondendo à solicitação escrita, retornar o outro conjunto de dados de status para o acionador de filtro intermediário, e acessar a informação para determinar que o outro conjunto de dados de status corresponde ao arquivo criado com a dica para não passar os outros dados de status para o acionador de filtro superior.

39. Método, de acordo com a reivindicação 38, caracterizado pelo fato de que ainda compreende receber um pedido de leitura iniciado no acionador de filtro intermediário correspondendo ao ar- quivo criado, enviar o pedido de leitura para o sistema de arquivos, receber outro conjunto de dados de status do sistema de arquivos correspondendo ao pedido de leitura , retornar o outro conjunto de dados de status para o acionador de filtro intermediário e acessar a informação para determinar que o outro conjunto de dados de status corresponde ao arquivo criado com a dica para não passar os outros dados de status para o acionador de filtro superior.

40. Sistema em um ambiente de computação tendo um sistema operacional e um sistema de arquivos (276), em que o sistema operacional inclui um componente (206) que recebe chamadas de funções relacionadas com o sistema de arquivo e fornece dados de pedido de l/O correspondentes direcionados para o sistema de arquivo, caracterizado pelo fato de que compreende: uma pluralidade de acionadores de filtro (282); e um gerenciador de filtro (212) adaptado para executar o método conforme definido em qualquer uma das reivindicações 1 a 39.

41. Meio legível por computador tendo nele armazenada uma estrutura de dados caracterizado pelo fato de que compreende: um primeiro conjunto de informações que identificam a estrutura como sendo associada a um tipo de pedido de sistema de arquivos de l/O; um segundo conjunto de informações que identifica uma pluralidade de acionadores de filtro associados com o tipo do pedido de sistema de arquivos l/O; e um terceiro conjunto de informação que identifica um ordenamento dos acionadores de filtro com relação um ao outro; em que cada um da pluralidade de acionadores de filtro é registada por pelo menos um dentre uma pré-chamada de retorno e uma pós-chamada de retorno na forma de um pedido de sistema de arquivo de l/O, e, em resposta a um pedido de sistema de arquivo de 1/0 correspondente ao primeiro conjunto de informações, uma entidade converte os dados no pedido de sistema de arquivos de 1/0 em dados de chamada de retorno para passar para os acionadores de filtro, a entidade chama cada um dos acionadores de filtro registrados para uma pré-chamada de retorno no segundo conjunto com uma pré-chamada de retorno em uma ordem determinada pelo terceiro conjunto de informações, a entidade recebe um valor de status a partir de cada acionador de filtro, em que o valor de status indica tanto sucesso quanto um pedido para não ser chamado de volta com uma pós-chamada de retorno, ou o sucesso e um pedido para ser chamado de volta com uma pós-chamada de retorno, a entidade reconverte os dados de chamada de retorno recebidos a partir de um último acionador de filtro registrado para uma pré-chamada de retorno em um pedido de sistema de arquivos reconvertido 1/0 e passa o pedido de sistema de arquivos reconvertida 1/0 para um sistema de arquivos (276), e a entidade retorna os dados correspondentes ao pedido de sistema de arquivo de 1/0 para um originador do pedido do sistema de arquivos 1/0 ao chamar de volta com uma pós-chamada de retorno os acionadores de filtro terem enviado os valores de status indicando sucesso e um pedido para ser chamado volta e não chamar os acionadores de filtro que enviaram valores de status indicando sucesso e um pedido para não ser chamado de volta, uma chamada de retorno sendo uma estrutura de dados contendo os dados de chamada de retorno, os dados de chamada de retorno fornecendo dados em um formato bem definido que difere do pedido de 1/0, uma pré-chamada de retorno sendo uma chamada de retorno para passar dados de chamada de retorno para um acionador de filtro a ser aplicado na forma do pedido de 1/0 para o sistema de arquivos, e uma pós-chamada de retorno sendo uma chamada de retorno para passar dados de chamada retorno para um filtro a ser apli- cado na forma do pedido de l/O de volta a partir do sistema de arquivos para um gerenciador de 1/0.

42. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o primeiro conjunto de informação corresponde a um pedido de sistema de arquivos l/O direcionado para criar um arquivo.

43. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o primeiro conjunto de informação corresponde a um pedido de sistema de arquivos de l/O direcionado a abrir um arquivo.

44. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o primeiro conjunto de informação corresponde a um pedido de sistema de arquivos de l/O dirigido a leitura de um arquivo.

45. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o primeiro conjunto de informação corresponde a um pedido de sistema de arquivos de l/O dirigido a gravação de um arquivo.

46. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o primeiro conjunto de informação corresponde a um pedido de sistema de arquivos de l/O direcionado para fechar um arquivo.

47. Meio legível por computador, de acordo com a reivindicação 41, caracterizado pelo fato de que o segundo conjunto de informação compreende uma lista de acionadores de filtro para chamar, e em que o terceiro conjunto de informações que identifica uma ordenação dos acionadores de filtro é incorporado na ordem dos acionadores de filtro dentro da lista.