[Arquivo de boletins informativos ^] <[ Volume 1, Número 4] [Volume 2, Número 1 >]
The Systems Internals Newsletter Volume 1, Número 5
http://www.sysinternals.com
Direitos Autorais 1999 Mark Russinovich
12 de outubro de 1999 - Nesta edição:
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
- NTFS para Windows 98/NTFSDOS Professional
- DebugView v3.21
- Filemon e Regmon v4.21
- Diskmon v1.1
- Internos de Sistemas na www.microsoft.com
- Outubro "NT Internals"
- Coisas não tão novas
NOTÍCIAS INTERNAS
- Win2K RC2 DDK Lançado
- Novas APIs do kernel Win2K RC
- Desenvolvimento de Software '99 Leste
- Usando o DiskEdit
O QUE VEM POR AÍ
- Explosão da API Win2K
PATROCINADOR: WINTERNALS SOFTWARE
A Newsletter Systems Internals é patrocinada pela Winternals Software, na Web em http://www.winternals.com. A Winternals Software é a principal desenvolvedora e fornecedora de ferramentas de sistemas avançados para Windows NT/2K. Os produtos Winternals Software incluem FAT32 para Windows NT 4.0, ERD Commander (capacidade de disco de inicialização para Windows NT) e NTRecover.
O Remote Recover da Winternals Software permite-lhe aceder às unidades de um computador não inicializável via TCP/IP a partir de qualquer lugar na sua empresa. Economize tempo e suporte corrigindo remotamente problemas de driver, sistema de arquivos e configuração que estão mantendo os sistemas NT ou Win9x off-line. Você pode até mesmo executar operações remotas de chkdsk ou particionamento usando a Recuperação Remota, o que a torna uma ferramenta versátil de recuperação de desastres. Faça o download de uma versão de avaliação gratuita somente leitura em http://www.sysinternals.com/rrecover.htm, e compre a versão de leitura/gravação em http://www.winternals.com.
Olá a todos,
Bem-vindo à newsletter da Systems Internals. A newsletter conta atualmente com 10.000 assinantes.
O lançamento do Windows 2000 (Win2K) parece seguir um padrão de se tornar iminente e, em seguida, ser empurrado para trás. Os rumores mais recentes são de que estará disponível em fevereiro. E a única informação sobre a data de lançamento do Win2K está em rumores, já que a Microsoft nem sequer está dizendo aos OEMs ou parceiros quando ele será lançado. Bem, eles são: "ele vai enviar quando estiver pronto" (não vou forçar o ditado datado sobre a venda de vinho em você aqui).
A coisa irritante sobre a Microsoft é que a imprensa que eles geram sobre seus produtos sempre faz parecer que eles estão à beira do envio, mesmo quando os produtos são vaporware. O exemplo mais recente é o Millennium, o sucessor do Windows 98. A Microsoft não muito tempo atrás fez um grande impulso na imprensa para ele como se fosse um produto acabado, pronto para converter todos os seus eletrodomésticos em dispositivos inteligentes. A ironia é que artigos pouco tempo depois revelaram que a Microsoft ainda nem definiu totalmente o produto, e provavelmente levará um ano ou mais até que o vejamos nas prateleiras das lojas.
Este padrão não é novo e não sou o primeiro a escrever sobre ele. Mas isso não me impede de especular sobre o quanto da gangorra é um plano cuidadosamente orquestrado, e quanto é o resultado de uma total falta de princípios de engenharia de software. Se você comprar o primeiro ângulo, como fazem os teóricos da conspiração, a Microsoft sufoca brilhantemente a concorrência ao seduzir os clientes com aquele produto incrível que, se eles esperarem um pouco mais, fará sua espera valer a pena e evitará qualquer necessidade de recorrer a um produto que não seja da Microsoft. Este último ângulo diz que a Microsoft nunca aprenderá o processo de desenvolvimento de software, e continuamente subestima o esforço de engenharia e superestima a qualidade do código beta.
Estou sentado em cima do muro sobre qual teoria eu atribuo. Na verdade, acho que o padrão se deve a um pouco de ambos. Acho que isso ajudou a Microsoft a agir como se o Ative Directory estivesse quase pronto há dois anos. Certamente há clientes que teriam recorrido ao Novell Directory Services há muito tempo se soubessem com antecedência quanto tempo teriam que esperar pelo Win2K. Por outro lado, a Microsoft tem recebido repetidos olhos negros na imprensa de prometer a entrega de produtos e depois atrasar. Eu acho que a gerência da Microsoft simplesmente não entende o quão difícil é reproduzir, isolar e corrigir esses últimos 5% dos bugs.
Falando das práticas de desenvolvimento da Microsoft, seu esquema de nomenclatura de pré-lançamento é um dos mais desconcertantes que já vi. Seus Betas são realmente Alphas e seus Release Candidates são na verdade Betas. E mesmo usar essas definições é um exagero: a Microsoft não tem problema em extrair recursos de seu software ao passar de um Release Candidate para o próximo, ou até mesmo adicionar novos. Eles fizeram isso com NT 4.0 e estão fazendo isso com Win2K. Essa prática certamente não acelera um ciclo de lançamento.
Então o Win2K será lançado em fevereiro? Penso que estamos a ver a luz ao fundo do túnel. Afinal, há apenas um punhado de novas APIs no RC2...
Na sequência da última newsletter onde falei sobre a confusão de siglas na Microsoft, o leitor George Janczuk encontrou outro exemplo. Na seção intitulada: "Estendendo-se ao mundo de processamento de transações de mainframe", o artigo em http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm refere-se a CISC - Complex Instruction set Computing. É óbvio para qualquer pessoa familiarizada com aplicativos de mainframe que a sigla pretendida é CICS - Customer Information Control System. Uma sequência de letras invertida e você está em uma área de tecnologia totalmente diferente.
Como de costume, por favor, passe a newsletter para amigos que você acha que podem achar interessante.
Obrigado!
-Marcar
O QUE HÁ DE NOVO NA SYSTEMS INTERNALS
NTFS PARA WINDOWS 98/NTFSDOS PROFESSIONAL
Finalmente conseguimos. Desde que Bryce e eu lançamos o NTFSDOS 1.0 na primavera de 1996, estamos em busca do santo graal da compatibilidade do sistema de arquivos do Windows: acesso de leitura/gravação para NTFS a partir do Windows 9x e DOS. Determinamos há muito tempo que a engenharia reversa do formato NTFS e escrever um driver para esse complexo sistema de arquivos de registro no diário seria uma proposta difícil e arriscada. Mesmo que se determine com precisão cada nuance do formato, uma atualização para o formato, como o NTFS v5.0 do Win2K, requer um esforço de engenharia reversa e desenvolvimento totalmente novo. Além disso, validar a correção de um driver de sistema de arquivos para um formato tão complexo quanto o do NTFS é uma proposta assustadora.
Então nós trapaceamos.
NTFS para Windows 98 fornece acesso total de leitura/gravação para unidades NTFS do Windows 95 ou Windows 98, e NTFSDOS Professional fornece acesso de leitura/gravação NTFS completo do DOS. Nem NTFS para Windows 98 nem NTFSDOS Professional tem qualquer conhecimento do formato de sistema de arquivos NTFS. Em vez disso, eles dependem do driver NTFS de uma instalação do Windows NT ou Windows 2000 para implementar esse conhecimento. Ambos os utilitários usam a mesma base de código que serve como um wrapper de ambiente para o driver do sistema de arquivos NTFS. NTFS para Windows 98 fornece uma interface para a API do sistema de arquivos do Windows 9x acima de NTFS e os serviços de disco do Windows 9x abaixo de NTFS. A interface NTFS para Windows 98 apresentada ao NTFS se parece com o ambiente nativo do NTFS Windows NT/2K, completo com IRPs, o Gerenciador de E/S, o Gerenciador de Cache, dispositivos de disco no estilo NT e outros subsistemas NT/2K com os quais o NTFS interage.
NTFSDOS Professional funciona da mesma maneira que NTFS para Windows 98, exceto que ele faz interface NTFS para serviços DOS acima e BIOS Interrupt 13 serviços de disco abaixo. Para ajudar a criar o ambiente NT/2K-like, contamos com muitas funções dentro do NTOSKRNL, o arquivo do kernel NT/2K. Ambos os utilitários carregam NTOSKRNL em conjunto com NTFS, para que o NTFS possa usar diretamente os serviços nativos do kernel.
Nós nos divertimos tanto construindo o ambiente NTFS que fomos um passo além: fizemos a mesma coisa com o utilitário chkdsk de inicialização da NT, Autochk. NTFSDOS Professional e NTFS para Windows 98 vêm com um utilitário NTFS chkdsk chamado NTFSCHK. NTFSCHK funciona na mesma entidade que o wrapper do sistema de arquivos NTFS, onde ele cria um ambiente semelhante ao NT para o programa Autochk para que o Autochk seja executado no Windows 95/98 e DOS. O resultado deste truque é o suporte completo de leitura/escrita NTFS para Windows 95/98 e para DOS.
Você pode baixar uma versão somente leitura gratuita do NTFS para Windows 98 em http://www.sysinternals.com/ntfs98.htm e uma versão somente leitura gratuita do NTFSDOS Professional em http://www.sysinternalscom/ntfspro.htm. Você pode comprar as versões completas de leitura/gravação de ambas as ferramentas em Winternals Software, http://www.winternals.com.
DEBUGVIEW V3.21
DebugView é um monitor de saída de depuração que captura o kernel e a saída de depuração do Win32 no Windows 95, Windows 98, NT 4.0 e Windows 2000. Ele tem recursos avançados de filtragem, realce e registro, e pode até mesmo capturar a saída de depuração de um sistema em uma rede. Sua última versão, 3.21, introduz a capacidade de monitorar a saída OutputDebugString de 16 bits no Windows 95 e Windows 98.
Você pode baixar DebugView v3.21 em http://www.sysinternals.com/dbgview.htm.
FILEMON E REGMON V4.21
Filemon e Regmon são sistema de arquivos e utilitários de espionagem do Registro para Windows 95, 98, NT 4.0 e Win2K. Eles continuam a evoluir com novos recursos de usabilidade e com a versão 4.21 (Filemon e Regmon têm números de versão sincronizados) eles introduzem filtragem mais avançada com listas de filtros recentes, a capacidade de definir um filtro de realce (com cores personalizadas mesmo), fonte personalizável, suporte à área de transferência e mais teclas de atalho compatíveis com CUI. O código-fonte do driver também foi reformulado e inclui uma validação de parâmetros mais robusta nas funções da interface GUI.
Download Filemon v4.21 em http://www.sysinternals.com/filemon.htm e Regmon v4.21 em http://www.sysinternals.com/regmon.htm.
DISKMON V1.1
Diskmon é uma ferramenta que monitora e exibe a atividade lógica e física do disco. A versão 1.1 atualiza o Diskmon para funcionar com o Windows 2000 e introduz novos aprimoramentos de usabilidade. Além disso, o Diskmon agora interpreta um grande número de códigos de controle de E/S de disco e armazenamento em massa, traduzindo seus códigos hexadecimais em representações de texto na janela de saída do Diskmon.
Diskmon v1.1 não só funciona como um monitor de disco, mas você pode usá-lo como uma luz de disco baseada em software também. Quando você o define no modo de luz de disco, Diskmon minimiza-se na bandeja do sistema como uma luz que é verde quando há acesso de leitura de disco e vermelho quando há acesso de gravação de disco.
Download Diskmon v1.1 em http://www.sysinternals.com/diskmon.htm.
INTERNOS DE SISTEMAS NA WWW.MICROSOFT.COM
Considerando a história da Systems Internals (anteriormente NT Internals), é realmente uma grande bajulação que a Microsoft faça referência a sysinternals.com como um recurso para seus clientes. Há um número crescente de artigos da Base de Dados de Conhecimento Microsoft que apontam para os utilitários Systems Internals. Aqui estão os mais recentes:
Q183060 INFO: Guia de solução de problemas para 80004005 & Outras mensagens de erro http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Este artigo descreve que você pode usar Filemon para verificar a causa de erros de acesso a dados no OLE DB, ActiveX Data Objects e Remote Data Service.Q196453 - Solução de problemas de erros de inicialização NTVDM e WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Este artigo também aponta para Filemon como uma ferramenta para determinar quais arquivos ausentes estão causando erros de inicialização para NTVDM (o ambiente de compatibilidade Win16/DOS no NT).Q216368 - PROBLEMA: Violação de acesso durante a instalação do aplicativo quando o arquivo em uso http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx e DLLView são ferramentas recomendadas para determinar a causa de erros durante a execução de programas de instalação gerados pelo Assistente de instalação do Visual Basic e Assistente de implantação.Q232830 - COMO: Determinar a propriedade do identificador de arquivo http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx novamente obtém a referência neste artigo que discute descobrir qual processo tem um arquivo ou diretório aberto.
OUTUBRO "NT INTERNALS"
Minha coluna "NT Internals" na edição de outubro da Windows NT Magazine é "Inside Win2K Reliability Enhancements, Part 3". Este terceiro de uma série de três partes descreve dois poderosos recursos do Win2K que ajudam desenvolvedores e administradores a identificar drivers com bugs: memória do kernel protegida contra gravação e o Verificador de Driver.
Os leitores russos podem agora ler os meus artigos na sua língua materna. Dirija-se à edição russa da Windows NT Magazine e http://www.osp.ru/win2000/ confira a primeira coluna traduzida do NT Internals, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Obrigado a Ivan Rouzanov por me informar sobre isso.
A partir do início de agosto, as versões on-line dos artigos da Windows NT Magazine são acessíveis apenas para assinantes, e os artigos são postados on-line a cada nova edição. Se você ainda não se inscreveu, acesse o link de assinatura para http://www.sysinternals.com/publ.htm obter o desconto de assinatura do Systems Internals.
COISAS NÃO TÃO NOVAS
WinObj é uma ferramenta poderosa para explorar o namespace de objeto do Windows NT/2K. O namespace Object é um dos três namespaces em NT/2K: o namespace Object, o namespace Registry e o namespace filesystem. Você chega aos namespaces Registro e sistema de arquivos por meio de objetos no namespace Object. Por exemplo, quando um programa Win32 abre a chave HKEY_LOCAL_MACHINE\Software\Microsoft do Registro, a biblioteca ADVAPI32.DLL transforma o nome em \Registry\Machine\Software\Microsoft antes de chamar o serviço NtCreateKeydo kernel. Se você olhar para a raiz do namespace Object no WinObj, verá um objeto do tipo "chave" chamado Registry. O nome do Registro corresponde ao primeiro componente do nome da chave e, portanto, o Gerenciador de Objetos NT/2K passa o restante do nome, \Machine\Software\Microsoft, para o subsistema que define o objeto de chave. O subsistema do kernel do Configuration Manager mantém o Registro e os objetos de chave, portanto, analisa o restante do nome para localizar a chave desejada.
Você pode explorar o namespace Object e exibir ou definir propriedades de segurança de objeto usando WinObj. Download Winobj em http://www.sysinternals.com/winobj.htm. Eu discuto o namespace do Gerenciador de Objetos e o WinObj na minha coluna NT Internals de outubro de 1997, "Dentro do Gerenciador de Objetos". Siga um link para a versão on-line da coluna em http://www.sysinternals.com/publ.htm.
NOTÍCIAS INTERNAS
WIN2K RC2 DDK LANÇADO
Você pode baixar a versão Win2K RC2 do Device Driver Development Kit (DDK) da Microsoft agora em http://www.microsoft.com/ddk/ddkRC2.htm. Você pode baixar o kit gratuitamente ou consultar a documentação on-line.
NOVAS APIS DO KERNEL WIN2K RC2
As coisas parecem estar estabilizando no kernel Win2K mais recente. Há apenas quatro novas APIs de kernel exportadas no RC3, em oposição a cerca de uma dúzia que apareceu (e outra meia dúzia que desapareceu) indo do Beta 3 para o RC1. Várias das novas funções são um pouco interessantes, então decidi documentá-las para você. O primeiro é MmGetSystemRoutineAddress, e embora não esteja documentado, seu protótipo está incluído no arquivo de cabeçalho ntddk.h do RC2 DDK:
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Seu uso é tão simples quanto parece. Passe o nome de uma função que reside em NTOSKRNL.EXE ou HAL.DLL e você receberá de volta seu endereço de ponto de entrada. Esta função é realmente inútil na primeira versão do Win2K, mas pode se tornar muito útil no futuro, e é uma função que a Microsoft deveria ter incluído na primeira versão do NT (3.1). Como GetProcAddress no espaço do usuário para aplicativos Win32, essa função permite que um driver verifique dinamicamente a disponibilidade de uma API. Se a Microsoft adicionar novas APIs aos service packs do Win2K (e tenho certeza de que o farão), os drivers podem ser escritos para aproveitar as APIs, mas também para falhar normalmente em versões mais antigas do Win2K ou para serem executados em um modo em que eles não usam as APIs. A chave para um driver ser capaz de fazer isso é a capacidade de verificar a presença das APIs após o carregamento. Sem essa funcionalidade, um driver tem que se vincular estaticamente com as funções que usa, e se as funções não estiverem presentes quando o driver carrega, o carregador do kernel relata um erro feio para o usuário e não consegue carregar o driver.
A segunda nova API é MmGetPhysicalMemoryPages. Mais uma vez, o seu protótipo está na RC2 ntddk.h, mas não está documentado. O seu protótipo é:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Onde PHYSICAL_MEMORY_RANGE está:
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Esta função retorna uma matriz de PHYSICAL_MEMORY_RANGE entradas com o final da matriz marcado por uma entrada que tem 0 para ambos e BaseAddress NumberOfBytes. Como MmGetSystemRoutineAddress, é uma API bastante simples. Ele retorna a você uma descrição de toda a memória física que o Win2K conhece. Win2K suporta a adição e remoção de memória em tempo real com o MmAddPhysicalMemory e MmRemovePhysicalMemory APIs. Isso motiva a razão da existência de uma API que permite consultar intervalos de memória. MmAddPhysicalMemory foi adicionado em RC1 e MmRemovePhysicalMemory em RC2. Ambas as funções também são prototipadas em ntddk.h.
Quais são as outras novas APIs RC2? PoShutdownBugCheck e RtlInvertRangeList. PoShutdownBugCheck permite que você trave o sistema e execute uma ação relacionada à energia, como a suspensão. É usado em alguns lugares pelo kernel RC2. Intervalos são especificações genéricas de início e fim que são definidas pelo usuário e suportadas por várias APIs do kernel para gerenciar, classificar e iterar sobre eles. Os árbitros de recursos Win2K Plug-and-Play usam-nos para controlar e organizar os requisitos de recursos de hardware. Embora as APIs de lista de intervalo não estejam documentadas, todos os seus protótipos e definições de estrutura estão incluídos em ntddk.h, portanto, você pode, presumivelmente, usar a API para gerenciar seus próprios dados orientados para start-end.
Fique atento para mais diversão com APIs não documentadas em boletins informativos subsequentes.
DESENVOLVIMENTO DE SOFTWARE 99 EAST
A edição de 1999 da Costa Leste do Desenvolvimento de Software terá lugar em Washington D.C. de 8 a 12 de novembro. Estou apresentando três palestras no último dia: O que há de novo no Windows 2000 para desenvolvedores, Dentro da tela azul do Windows NT/2000 e Dentro da rede do Windows NT/2000. Além disso, Dave Solomon, autor de Inside Windows NT 2nd Edition e um vizinho (ele mora a meros 20 minutos de mim em, de todos os lugares, Danbury, CT), e eu estamos hospedando uma mesa redonda interna do Windows NT/2K. Estaremos juntos para responder às suas perguntas mais difíceis sobre os componentes internos do Windows NT/2K. Diga olá e mencione a newsletter e eu lhe darei uma camiseta gratuita da Systems Internals!
Visite o site de Desenvolvimento de Software em http://www.sdexpo.com.
USANDO O DISKEDIT
Talvez você não saiba, mas há um utilitário editor de disco para Windows NT no estilo do venerável Norton Disk Edit para DOS. Além disso, o utilitário entende FAT e NTFS e é gratuito. A Microsoft aparentemente enviou o DiskEdit acidentalmente, uma ferramenta que deve ser uma ferramenta de depuração interna para suas equipes de sistemas de arquivos, no CD do Windows NT 4.0 Service Pack 4. O DiskEdit tem uma interface peculiar que levaria um pequeno manual para documentar, mas vou começar com um passo a passo simples. Vou me concentrar em usar o DiskEdit para desvendar o formato do sistema de arquivos NTFS, já que o DiskEdit é a única ferramenta disponível publicamente que conheço que entende NTFS.
Primeiro, você precisa obter o DiskEdit do CD-ROM do Service Pack 4 (SP4). Basta copiá-lo do diretório \i386 para o disco rígido. Se você quiser usar o DiskEdit em Win2K, precisará criar um diretório privado para ele e copiar as seguintes DLLs de um diretório winnt\system32 do SP4 (ou CD do SP4) para o mesmo diretório do DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL e UFAT.DLL. Agora você pode iniciar o DiskEdit.
Para este passo a passo, crie um diretório chamado TEMP na raiz de uma unidade NTFS e crie um arquivo chamado OUT.TXT nesse diretório digitando o seguinte comando em uma janela de prompt de comando com TEMP como o diretório atual: echo hello > out.txt. Selecione a unidade com seu novo arquivo OUT.TXT no DiskEdit escolhendo o arquivo |Abra o item de menu e insira a letra da unidade no campo Nome do Volume da caixa de diálogo resultante. Certifique-se de que inclui os dois pontos, por exemplo, "d:". Praticamente todas as funcionalidades do DiskEdit exigem que você tenha aberto uma unidade.
Vamos localizar o arquivo OUT.TXT começando no diretório raiz da unidade NTFS. Selecione a entrada do menu Ler|Registo de Ficheiros NTFS para abrir uma caixa de diálogo que lhe permite visualizar qualquer entrada de registo MFT apenas introduzindo o respetivo número. As primeiras 16 entradas de registo MFT de cada unidade NTFS são reservadas e correspondem a ficheiros de metadados NTFS predefinidos. Aqui estão as atribuições numéricas (observe que o DiskEdit interpreta todas as entradas como hexadecimais):
0: $MFT - MFT
1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
2: $LogFile - NTFS LogFile
3: $Volume - volume information file
4: $AttrDef - the attribute definition file
5: . - the root directory
6: $Bitmap - the volume allocation bitmap file
7: $Boot - the boot sector
8: $BadClus - the bad cluster database file
9: $Secure - new to SP4, the security attribute database
A: $UpCase - the lower-to-upper case mapping file
B: $Extend - new to Win2K, the directory that contains
the reparse, object ID, and quota metadata files
C-F: Unused as of NTFS v5.0 (Win2K)
Vá em frente e veja algumas dessas entradas MFT. Você começará a notar um tema comum: todos eles consistem em atributos como $INDEX_ROOT, $FILE_NAME, e $DATA. É em atributos onde os dados específicos de um arquivo são armazenados. Quando os dados do atributo são pequenos, o NTFS armazena os dados dentro do registro MFT do arquivo como dados "residentes" e, quando os dados são grandes, o NTFS armazena os dados externos ao registro em clusters no disco como dados "não residentes".
Agora digite "5" como o número do arquivo e você estará visualizando o arquivo do diretório raiz. Vamos examinar os arquivos e diretórios que estão no diretório raiz exibindo o atributo do $INDEX_ALLOCATION diretório, um atributo específico para diretórios que registra o conteúdo de um diretório. Para fazer isso, selecione o botão Ler|Entrada de menu Atributo NTFS, que abre outra caixa de diálogo. O DiskEdit é sensível a maiúsculas e minúsculas, por isso introduza o seguinte precisamente como o listei:
Base Frs Number: 5
Base Frs (Base File Record Segment) é outro nome para o número MFT. Você digita para 5 para especificar que deseja ler um atributo do diretório raiz.
Attribute Type: $INDEX_ALLOCATION
Isso indica ao DiskEdit que você deseja ler os dados de conteúdo do diretório. Eu recomendo usar o menu suspenso para escolher o atributo desejado, pois o DiskEdit é muito exigente sobre a maneira como o tipo de atributo é inserido.
Attribute Name: $I30
Se você visualizar o $INDEX_ALLOCATION atributo do diretório raiz, verá que "$I30" está listado como seu nome em sua linha "Type code, name", então é isso que você insere como o nome do atributo.
Pressione OK e você verá um despejo hexadecimal do conteúdo do atributo. Queremos ver algo mais inteligível, por isso selecione a opção Ver|Entrada do menu NTFS Index Buffer. Ser-lhe-á apresentada a listagem do conteúdo do diretório. Percorra a listagem até ver a entrada que tem o nome "TEMP". Se você não vê-lo, a entrada pode estar localizada no atributo do diretório raiz, um tipo de $INDEX_ROOT atributo também associado a diretórios e que sempre tem seu valor armazenado no registro MFT. As entradas raiz do índice e as entradas de alocação juntas formam uma estrutura de árvore B+ que armazena todas as entradas de um diretório. Se você tiver que visualizar o $INDEX_ROOT atributo basta seguir as mesmas etapas para visualizar esse atributo como você fez para visualizar o $INDEX_ALLOCATION atributo. Ao percorrer um buffer de índice, você pode se deparar com linhas duplas de asteriscos: elas designam o final de um buffer de índice e o início do próximo.
Depois de encontrar a entrada do diretório TEMP, anote sua Referência de arquivo (FRS). Selecione Ler|Registro de arquivo NTFS e digite FRS de TEMP. Agora você está olhando para o registro MFT para o diretório TEMP. Queremos encontrar o arquivo OUT.TXT, então teremos que examinar o conteúdo do TEMP para encontrá-lo. Exiba o $INDEX_ALLOCATION atributo (ou ) do diretório TEMP, alterne $INDEX_ROOTpara exibir os dados como um buffer de índice NTFS e localize o arquivo OUT.TXT. Lembre-se de inserir o FRS do TEMP como o número FRS base na caixa de diálogo de seleção de atributos. Se você acabou de criar o TEMP, ele só terá um $INDEX_ROOT (se você digitar algo errado, você terá o prazer de ver nas caixas de diálogo de erro vazias do DiskEdit).
Quando você encontrar OUT.TXT e determinar seu FRS, use Read|Registro de arquivo NTFS para examinar sua entrada MFT. Role para baixo até encontrar o atributo $DATA. Agora você está olhando para a localização do OUT. Dados do TXT. Como fizemos um pequeno arquivo, os dados são armazenados no registro MFT. Se você tentar visualizar OUT. O atributo TXT $DATA usando o DiskEdit você não verá nada, já que o DiskEdit não mostra corretamente os dados residentes (um dos muitos bugs do DiskEdit). Então, copie um arquivo de texto largish (> 2KB) para \TEMP\ OUT.TXT. Agora você pode visualizar os dados OUT.TXT de duas maneiras: você pode examinar o início dos dados (ou todos eles, se estiverem armazenados contíguamente no disco) usando Read|Cluster NTFS e especificando o primeiro valor "lcn" que você vê em OUT. TXT $DATA atributo "Extensão List"; ou você pode usar Read|Atributo NTFS e digite "$DATA" como o tipo de atributo e nada (como em não digite nada nesse campo) como o nome do atributo.
As listas de extensão descrevem a localização dos dados não residentes de um atributo. Cada bloco contíguo de dados de até 16 clusters de comprimento é descrito por uma entrada de lista de extensão. Uma entrada de lista de extensão especifica um número de cluster virtual (vcn), número de cluster lógico (lcn) e comprimento de execução. Um Vcn é o cluster dentro do arquivo no qual os dados descritos pela entrada começam. Um Lcn designa o cluster lógico onde os dados são armazenados no disco e o comprimento de execução é o número de bytes de dados de atributo nesse local (lembre-se, DiskEdit está mostrando valores hexadecimais).
Eu guiei você através do longo caminho de encontrar o registro MFT do arquivo OUT.TXT, mostrando-lhe como verificar o conteúdo do diretório. No entanto, há um atalho: selecione Crack|Caminho NTFS e digite TEMP\OUT.TXT. Você será presenteado com OUT. TXT FRS e você pode usar Read|Registro de arquivo NTFS para ir direto para ele.
Isso me leva ao final da minha cartilha do DiskEdit. Eu encorajo você a brincar com esta ferramenta bacana navegando em suas unidades FAT ou NTFS. É altamente improvável que você encontre ocasião para usar o DiskEdit para modificar dados, a fim de tirar seu disco de um congestionamento, mas se você estiver curioso sobre o formato NTFS no disco (o formato FAT é bem documentado), esta é a ferramenta perfeita para investigar.
O QUE VEM POR AÍ
EXPLOSÃO DA API WIN2K
Embora existam apenas 4 novas APIs exportadas em modo kernel que fizeram sua estreia no RC2, o número total de APIs que a Microsoft introduziu desde o NT 4.0, tanto no kernel quanto nas DLLs Win32 principais, explodiu. No próximo mês, vou dizer-lhe exatamente quantas novas APIs existem e onde elas apareceram, e infelizmente, ao mesmo tempo, dar às pessoas que acreditam que o Win2K é um monstro inchado alguma grande munição para seus discursos alt.advocacy.linux Usenet.
Obrigado por ler a Newsletter da Systems Internals.
Publicado quarta-feira, 20 de outubro de 1999 19:10 por ottoh
[Arquivo de boletins informativos ^] <[ Volume 1, Número 4] [Volume 2, Número 1 >]