[Archivio newsletter ^] [< Volume 1, Numero 4] [Volume 2, Numero 1 >]
Newsletter Systems Internals Volume 1, Numero 5
http://www.sysinternals.com
Copyright 1999 Mark Russinovich
12 ottobre 1999 - In questo numero:
NOVITÀ DI SYSTEMS INTERNALS
- NTFS per Windows 98/NTFSDOS Professional
- DebugView v3.21
- Filemon e Regmon v4.21
- Diskmon v1.1
- Systems Internals in www.microsoft.com
- "NT Internals" - Numero di ottobre
- Notizie quasi recenti
NOVITÀ DI INTERNALS
- DDK Win2K RC2 rilasciato
- Nuove API kernel Win2K RC
- Software Development '99 East
- Uso di DiskEdit
SVILUPPI FUTURI
- Esplosione dell'API Win2K
SPONSOR: WINTERNALS SOFTWARE
La newsletter Systems Internals è sponsorizzata da Winternals Software, presente sul Web all'indirizzo http://www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K. I prodotti Winternals Software includono FAT32 per Windows NT 4.0, ERD Commander (funzionalità del disco di avvio per Windows NT) e NTRecover.
Remote Recover di Winternals Software consente di accedere alle unità di un computer non avviabile tramite TCP/IP da qualsiasi posizione dell'azienda. È possibile risparmiare tempo e costi per il supporto correggendo in remoto i problemi di driver, file system e configurazione che rendono inattivi i sistemi NT o Win9x. Remote Recover consente anche di eseguire operazioni remote di chkdsk o partizionamento ed è quindi uno strumento versatile per il ripristino di emergenza. Scaricare una versione di valutazione di sola lettura gratuita all'indirizzo http://www.sysinternals.com/rrecover.htm e acquistare la versione di lettura/scrittura all'indirizzo http://www.winternals.com.
Ciao a tutti.
Benvenuti nella newsletter System Internals. La newsletter conta attualmente 10.000 abbonati.
Il rilascio di Windows 2000 (Win2K) sembra essere sempre imminente per poi essere rimandato. Secondo le ultime voci, sarà disponibile a febbraio. Le uniche informazioni sulla data di disponibilità di Win2K sono voci, poiché Microsoft non dice nemmeno agli OEM o ai partner quando sarà disponibile. Dicono "Sarà disponibile quando sarà pronto". Forse migliora invecchiando come il vino...
La cosa irritante di Microsoft è che l'interesse mediatico che genera sui suoi prodotti fa sempre pensare che il lancio sia imminente, anche quando i prodotti sono vaporware. L'esempio più recente è Millennium, il successore di Windows 98. Microsoft, non molto tempo fa, ha fatto una grande promozione sulla stampa, come se fosse un prodotto finito, pronto a convertire tutti gli elettrodomestici in dispositivi intelligenti. L'ironia è che gli articoli di poco tempo dopo hanno rivelato che Microsoft non ha ancora definito completamente il prodotto e probabilmente ci vorrà un anno o più prima di vederlo sugli scaffali dei negozi.
Questo modus operandi non è nuovo e non sono il primo a scriverne. Ma questo non mi impedisce di formulare ipotesi su quanto questa altalena sia un piano attentamente orchestrato e su quanto sia il risultato di una totale mancanza di principi dell'ingegneria del software. Se si crede al primo punto di vista, come fanno i teorici della cospirazione, Microsoft soffoca brillantemente la concorrenza stuzzicando i clienti con quel prodotto incredibile che, se aspettano solo un po' di più, renderà la loro attesa proficua e ovvierà a qualsiasi necessità di rivolgersi a un prodotto non-Microsoft. Quest'ultimo punto di vista afferma che Microsoft non imparerà mai il processo di sviluppo del software e sottovaluta costantemente le attività ingegneristiche sopravvalutando la qualità del codice beta.
Sono indeciso su quale teoria seguire. In realtà penso che il modus operandi sia dovuto un po' a entrambe le cose. Credo che abbia aiutato Microsoft a comportarsi come se Active Directory fosse quasi pronto da due anni. Sicuramente ci sono clienti che si sarebbero rivolti a Novell Directory Services molto tempo fa, se avessero saputo in anticipo quanto avrebbero dovuto aspettare per Win2K. D'altra parte, Microsoft ha ricevuto duri colpi dalla stampa per aver promesso la consegna del prodotto e aver poi ritardato. Credo che la dirigenza di Microsoft non capisca quanto sia difficile riprodurre, isolare e risolvere quell'ultimo 5% di bug.
A proposito delle pratiche di sviluppo di Microsoft, il suo schema di denominazione pre-release è uno dei più sconcertanti che abbia mai visto. Le sue beta sono in realtà delle alfa e i suoi candidati al rilascio sono in realtà delle beta. E anche usare queste definizioni è una forzatura: Microsoft non ha problemi a togliere funzioni dal proprio software nel passaggio da un candidato al rilascio all'altro, o addirittura ad aggiungerne di nuove. L'ha fatto con NT 4.0 e lo sta facendo con Win2K. Questa pratica non accelera certamente un ciclo di rilascio.
Quindi Win2K sarà disponibile a febbraio? Penso che stiamo vedendo la luce alla fine del tunnel. Dopo tutto, ci sono solo una manciata di nuove API in RC2...
Facendo seguito all'ultima newsletter in cui ho parlato della confusione con gli acronimi in Microsoft, il lettore George Janczuk ha trovato un altro esempio. Nella sezione intitolata: "Extending to the Mainframe Transaction-Processing World", l'articolo all'indirizzo http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm fa riferimento al CISC - Complex Instruction Set Computing. È ovvio per chiunque abbia familiarità con le applicazioni mainframe che l'acronimo corretto è CICS - Customer Information Control System. Una sequenza di lettere invertite e ti ritrovi in un'area tecnologica completamente diversa.
Come di consueto, vi invito a condividere la newsletter con gli amici che potrebbero trovarla interessante.
Grazie.
- Mark
NOVITÀ DI SYSTEMS INTERNALS
NTFS PER WINDOWS 98/NTFSDOS PROFESSIONAL
Finalmente ce l'abbiamo fatta. Da quando Bryce ed io abbiamo rilasciato NTFSDOS 1.0 nella primavera del 1996, abbiamo cercato il Sacro Graal della compatibilità del file system di Windows: l'accesso in lettura/scrittura per NTFS da Windows 9x e DOS. Abbiamo compreso molto tempo fa che il reverse engineering del formato NTFS e la scrittura di un driver per questo complesso file system journaling sarebbero stati un'impresa difficile e rischiosa. Anche se si determina con precisione ogni sfumatura del formato, un aggiornamento del formato, come NTFS v5.0 di Win2K, richiede attività di reverse engineering e sviluppo completamente nuove. Inoltre, convalidare la correttezza di un driver di file system per un formato così intricato come quello NTFS è un'impresa davvero ardua.
Quindi abbiamo usato un trucco.
NTFS per Windows 98 offre un accesso completo in lettura/scrittura alle unità NTFS da Windows 95 o Windows 98, mentre NTFSDOS Professional offre un accesso completo in lettura/scrittura a NTFS da DOS. Né NTFS per Windows 98 né NTFSDOS Professional conoscono il formato del file system NTFS. Si affidano invece al driver NTFS di un'installazione di Windows NT o Windows 2000 per implementare questa nozione. Entrambe le utilità usano la stessa base di codice che funge da ambiente wrapper per il driver del file system NTFS. NTFS per Windows 98 fornisce un'interfaccia all'API del file system di Windows 9x sopra NTFS e ai servizi disco di Windows 9x sotto NTFS. L'interfaccia che NTFS per Windows 98 presenta a NTFS somiglia all'ambiente nativo di Windows NT/2K, completo di IRP, I/O Manager, Cache Manager, dispositivi disco in stile NT e altri sottosistemi NT/2K con cui NTFS interagisce.
NTFSDOS Professional funziona come NTFS per Windows 98, ma interfaccia NTFS con i servizi DOS sopra e con i servizi disco BIOS Interrupt 13 sotto. Per contribuire a creare l'ambiente simile a NT/2K, ci affidiamo a molte funzioni di NTOSKRNL, il file del kernel di NT/2K. Entrambe le utilità caricano NTOSKRNL insieme a NTFS, in modo che NTFS possa usare direttamente i servizi nativi del kernel.
Ci siamo divertiti così tanto a creare l'ambiente NTFS che abbiamo fatto un ulteriore passo avanti: abbiamo fatto la stessa cosa con l'utilità chkdsk di avvio di NT, Autochk. NTFSDOS Professional e NTFS per Windows 98 sono dotati di un'utilità NTFS chkdsk denominata NTFSCHK. NTFSCHK funziona in base allo stesso principio del wrapper del file system NTFS, dove crea un ambiente simile a NT per il programma Autochk, in modo che Autochk funzioni in Windows 95/98 e DOS. Il risultato di questo trucco è un supporto completo di lettura/scrittura NTFS per Windows 95/98 e DOS.
È possibile scaricare una versione gratuita di sola lettura di NTFS per Windows 98 all'indirizzo http://www.sysinternals.com/ntfs98.htm e una versione gratuita di sola lettura di NTFSDOS Professional all'indirizzo http://www.sysinternalscom/ntfspro.htm. È possibile acquistare le versioni complete di lettura/scrittura di entrambi gli strumenti da Winternals Software, http://www.winternals.com.
DEBUGVIEW V3.21
DebugView è un monitor di output debug che acquisisce l'output di debug del kernel e di Win32 in Windows 95, Windows 98, NT 4.0 e Windows 2000. Include funzionalità avanzate di filtro, evidenziazione e registrazione e può anche acquisire l'output di debug da un sistema in una rete. La versione più recente, 3.21, introduce la possibilità di monitorare l'output di OutputDebugString a 16 bit in Windows 95 e Windows 98.
È possibile scaricare DebugView v3.21 all'indirizzo http://www.sysinternals.com/dbgview.htm.
FILEMON E REGMON V4.21
Filemon e Regmon sono utilità di sorveglianza del file system e del Registro di sistema per Windows 95, 98, NT 4.0 e Win2K. Continuano a evolversi con nuove caratteristiche di usabilità e con la versione 4.21 (Filemon e Regmon hanno numeri di versione sincronizzati) introducono un filtraggio più avanzato con elenchi di filtri recenti, la possibilità di definire un filtro di evidenziazione (anche con colori personalizzati), un font personalizzabile, il supporto per gli Appunti e un maggior numero di tasti di scelta rapida compatibili con CUI. Il codice sorgente del driver è stato rielaborato e include anche una convalida dei parametri più affidabile nelle funzioni dell'interfaccia GUI.
Scaricare Filemon v4.21 all'indirizzo http://www.sysinternals.com/filemon.htm e Regmon v4.21 all'indirizzo http://www.sysinternals.com/regmon.htm.
DISKMON V1.1
Diskmon è uno strumento che monitora e visualizza l'attività del disco logico e fisico. La versione 1.1 aggiorna Diskmon per funzionare con Windows 2000 e introduce nuovi miglioramenti di usabilità. Inoltre, Diskmon interpreta ora un gran numero di codici di controllo I/O del disco e dell'archiviazione di massa, traducendo i codici esadecimali in rappresentazioni di testo nella finestra di output di Diskmon.
Diskmon v1.1 non funziona solo come monitor del disco, ma può essere usato anche come indicatore del disco basato sul software. Quando si imposta questa modalità, Diskmon si riduce a icona nella barra delle applicazioni come una luce verde quando c'è un accesso al disco in lettura e rossa quando c'è un accesso al disco in scrittura.
Scaricare Diskmon v1.1 all'indirizzo http://www.sysinternals.com/diskmon.htm.
SYSTEMS INTERNALS IN WWW.MICROSOFT.COM
Considerando la storia di Systems Internals (precedentemente NT Internals), è davvero una grande lusinga che Microsoft faccia riferimento a sysinternals.com come risorsa per i suoi clienti. C'è un numero crescente di articoli della Microsoft Knowledge Base che puntano alle utilità di Systems Internals. Ecco i più recenti:
Q183060 INFO: Guida alla risoluzione dei problemi per 80004005 e altri messaggi di errore http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Questo articolo descrive la possibilità di usare Filemon per verificare la causa degli errori di accesso ai dati in OLE DB, ActiveX Data Objects e Remote Data Service.Q196453 - Troubleshooting NTVDM and WOW Startup Errors http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Questo articolo indica anche Filemon come strumento per determinare quali sono i file mancanti che causano errori di avvio per NTVDM, l'ambiente di compatibilità Win16/DOS in NT.Q216368 - PRB: Access Violation During Application Setup When File in Use http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx e DLLView sono strumenti consigliati per determinare la causa degli errori durante l'esecuzione dei programmi di configurazione generati da Visual Basic Setup Wizard e Deployment Wizard.Q232830 - HOWTO: Determine File Handle Ownership http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx viene di nuovo citato in questo articolo che descrive come scoprire quale processo ha un file o una directory in stato di apertura.
"NT INTERNALS" - NUMERO DI OTTOBRE
La mia rubrica "NT Internals" nel numero di ottobre di Windows NT Magazine si intitola "Inside Win2K Reliability Enhancements, Part 3". Questa terza di una serie di tre parti descrive due potenti funzioni di Win2K che aiutano gli sviluppatori e gli amministratori a individuare i driver difettosi: la memoria del kernel protetta da scrittura e Driver Verifier.
I lettori russi possono ora leggere i miei articoli nella loro lingua madre. Visitate l'edizione russa di Windows NT Magazine all'indirizzo http://www.osp.ru/win2000/ e date un'occhiata alla prima rubrica tradotta di NT Internals, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Grazie a Ivan Rouzanov per avermi informato al riguardo.
Dall'inizio di agosto, le versioni online degli articoli di Windows NT Magazine sono accessibili solo agli abbonati e gli articoli vengono pubblicati online con ogni nuovo numero. Se non si è abbonati, usare il link per l'abbonamento a Systems Internals all'indirizzo http://www.sysinternals.com/publ.htm per ottenere lo sconto sull'abbonamento a Systems Internals.
NOTIZIE QUASI RECENTI
WinObj è un potente strumento per esplorare lo spazio dei nomi degli oggetti di Windows NT/2K. Lo spazio dei nomi degli oggetti è uno dei tre spazi dei nomi di NT/2K: lo spazio dei nomi degli oggetti, lo spazio dei nomi del Registro e lo spazio dei nomi del file system. Si accede agli spazi dei nomi del Registro e del file system tramite gli oggetti dello spazio dei nomi degli oggetti. Ad esempio, quando un programma Win32 apre la chiave HKEY_LOCAL_MACHINE\Software\Microsoft del Registro, la libreria ADVAPI32.DLL trasforma il nome in \Registry\Machine\Software\Microsoft prima di chiamare il servizio kernel NtCreateKey. Se si osserva la radice dello spazio dei nomi degli oggetti in WinObj, si vedrà un oggetto di tipo "key" denominato Registry. Il nome del Registro corrisponde al primo componente del nome della chiave e quindi NT/2K Object Manager passa il resto del nome, \Machine\Software\Microsoft, al sottosistema che definisce l'oggetto chiave. Il sottosistema kernel di Configuration Manager gestisce gli oggetti Registro e chiave, quindi analizza il resto del nome per individuare la chiave desiderata.
È possibile esplorare lo spazio dei nomi degli oggetti e visualizzare o impostare le proprietà di sicurezza degli oggetti usando WinObj. Scaricare Winobj all'indirizzo http://www.sysinternals.com/winobj.htm. Ho parlato dello spazio dei nomi Object Manager e di WinObj nella mia rubrica NT Internals di ottobre 1997, "Inside the Object Manager". Seguire un collegamento alla versione on-line della colonna all'indirizzo http://www.sysinternals.com/publ.htm.
NOVITÀ DI INTERNALS
DDK WIN2K RC2 RILASCIATO
È possibile scaricare la versione Win2K RC2 di Microsoft Device Driver Development Kit (DDK) all'indirizzo http://www.microsoft.com/ddk/ddkRC2.htm. È possibile scaricare gratuitamente il kit o consultare la documentazione online.
NUOVE API KERNEL WIN2K RC2
Sembra che le cose si stiano stabilizzando nell'ultimo kernel Win2K. Ci sono solo quattro nuove API del kernel esportate in RC3, rispetto alla dozzina che sono apparse (e un'altra mezza dozzina che sono scomparse) nel passaggio da beta 3 a RC1. Alcune delle nuove funzioni sono piuttosto interessanti, quindi ho deciso di parlarne. La prima è MmGetSystemRoutineAddress, e anche se non è documentata, il suo prototipo è incluso nel file di intestazione ntddk.h del DDK RC2:
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Il suo utilizzo è semplice come sembra. Inserendo il nome di una funzione che risiede in NTOSKRNL.EXE o HAL.DLL, si otterrà il suo indirizzo di ingresso. Questa funzione è in realtà inutile nella prima versione di Win2K, ma potrebbe diventare molto utile in seguito ed è una funzione che Microsoft avrebbe dovuto includere nella prima versione di NT (3.1). Come GetProcAddress nello spazio utente per le applicazioni Win32, questa funzione consente a un driver di verificare dinamicamente la disponibilità di un'API. Se Microsoft aggiunge nuove API ai service pack di Win2K (e sono sicuro che lo farà), potranno essere scritti driver per sfruttare le API, ma anche per generare errori con eleganza nelle vecchie versioni di Win2K o per funzionare in una modalità in cui non usano le API. La chiave per far sì che un driver sia in grado di eseguire queste operazioni è la capacità di verificare la presenza delle API dopo il caricamento. Senza questa funzionalità, un driver deve collegarsi staticamente alle funzioni che usa, e se le funzioni non sono presenti al momento del caricamento del driver, il caricatore del kernel segnala un errore grave all'utente e non riesce a caricare il driver.
La seconda nuova API è MmGetPhysicalMemoryPages. Ancora una volta, il suo prototipo si trova in RC2 ntddk.h, ma non è documentato. Il prototipo è:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Dove PHYSICAL_MEMORY_RANGE è:
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Questa funzione restituisce una matrice di voci PHYSICAL_MEMORY_RANGE con la fine della matrice contrassegnata da una voce che ha 0 per BaseAddress e NumberOfBytes. Come MmGetSystemRoutineAddress, si tratta di un'API piuttosto semplice. Restituisce una descrizione di tutta la memoria fisica che Win2K conosce. Win2K supporta l'aggiunta e la rimozione di memoria in tempo reale con le API MmAddPhysicalMemory e MmRemovePhysicalMemory. Questo spiega il motivo dell'esistenza di un'API che consente di eseguire query sugli intervalli di memoria. MmAddPhysicalMemory è stata aggiunta in RC1 e MmRemovePhysicalMemory in RC2. Anche queste due funzioni sono inserite come prototipo in ntddk.h.
Quali sono le altre nuove API RC2? PoShutdownBugCheck e RtlInvertRangeList. PoShutdownBugCheck consente di arrestare il sistema in modo anomalo ed eseguire un'azione correlata all'alimentazione, ad esempio la sospensione. Viene usato in un paio di posizioni dal kernel RC2. Gli intervalli sono specifiche generiche di inizio-fine definite dall'utente e supportate da una serie di API del kernel per la gestione, l'ordinamento e l'iterazione su di essi. Gli arbitri di risorse Win2K Plug-and-Play li utilizzano per tracciare e organizzare i requisiti delle risorse hardware. Anche se le API range-list non sono documentate, tutti i loro prototipi e le definizioni delle strutture sono inclusi in ntddk.h, quindi è presumibilmente possibile usare le API per gestire i dati orientati a inizio-fine.
Seguiranno ulteriori attività divertenti con le API non documentate nelle newsletter successive.
SOFTWARE DEVELOPMENT 99 EAST
L'edizione 1999 East Coast di Software Development si svolge a Washington D.C. dall'8 al 12 novembre. L'ultimo giorno presenterò tre interventi: cosa c'è di nuovo in Windows 2000 per gli sviluppatori, la schermata blu di Windows NT/2000 e la rete di Windows NT/2000. Inoltre, Dave Solomon, autore di Inside Windows NT 2nd Edition e vicino di casa (vive a soli 20 minuti da me proprio a Danbury, CT) ed io ospiteremo una tavola rotonda sui componenti interni di Windows NT/2K. Saremo insieme per rispondere anche alle domande più complicate sull'interno di Windows NT/2K. Se passate a salutarci e menzionate la newsletter, riceverete in regalo una t-shirt di Systems Internals!
Visitare il sito Web di Software Development all'indirizzo http://www.sdexpo.com.
USO DI DISKEDIT
Per chi non lo sapesse, esiste un'utilità di editor di dischi per Windows NT nello stile del venerabile Norton Disk Edit per DOS. Inoltre, l'utilità può gestire FAT e NTFS ed è gratuita. A quanto pare, Microsoft ha messo a disposizione DiskEdit accidentalmente, trattandosi di uno strumento di debugging interno per i team dedicati ai file system, sul CD di Windows NT 4.0 Service Pack 4. DiskEdit ha un'interfaccia particolare che richiederebbe un piccolo manuale per la spiegazione, ma io userò una semplice procedura dettagliata. Mi concentrerò sull'utilizzo di DiskEdit per spiegare il formato del file system NTFS, dato che DiskEdit è l'unico strumento disponibile pubblicamente che conosco in grado di gestire NTFS.
Per prima cosa è necessario prelevare DiskEdit dal CD-ROM del Service Pack 4 (SP4). È sufficiente copiarlo dalla directory \i386 al disco rigido. Se si vuole usare DiskEdit sotto Win2K, sarà necessario creare una directory privata e copiare le DLL seguenti da una directory SP4 winnt\system32 (o dal CD SP4) nella stessa directory di DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL e UFAT.DLL. Ora è possibile avviare DiskEdit.
Per questa procedura dettagliata, creare una directory chiamata TEMP nella radice di un'unità NTFS e creare un file chiamato OUT.TXT in tale directory digitando il comando seguente in una finestra del prompt dei comandi con TEMP come directory corrente: echo hello > out.txt. Selezionare l'unità con il nuovo file OUT.TXT in DiskEdit scegliendo la voce di menu File|Open e inserendo la lettera dell'unità nel campo Volume Name della finestra di dialogo visualizzata. Assicurarsi di includere i due punti, ad esempio "d:". Praticamente tutte le funzionalità di DiskEdit richiedono l'apertura di un'unità.
Il file OUT.TXT verrà individuato iniziando dalla directory radice dell'unità NTFS. Selezionare la voce di menu Read|NTFS File Record per aprire una finestra di dialogo che consente di visualizzare qualsiasi voce di record MFT semplicemente inserendone il numero. Le prime 16 voci del record MFT di ogni unità NTFS sono riservate e corrispondono a file di metadati NTFS predefiniti. Ecco le assegnazioni dei numeri. Si noti che DiskEdit interpreta tutti gli input come esadecimali:
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)
Osserviamo alcune di queste voci MFT. Si noterà un tema comune: sono tutti costituiti da attributi come $INDEX_ROOT, $FILE_NAME, e $DATA. È negli attributi che vengono memorizzati i dati specifici di un file. Quando i dati degli attributi sono di piccole dimensioni, NTFS archivia i dati all'interno del record MFT del file come dati "residenti", mentre quando i dati sono di grandi dimensioni NTFS archivia i dati esterni al record in cluster sul disco come dati "non residenti".
Immettere ora "5" come numero di file e si visualizzerà il file della directory radice. Verranno esaminati i file e le directory presenti nella directory radice visualizzando l'attributo $INDEX_ALLOCATION della directory, un attributo specifico delle directory che ne registra il contenuto. A tale scopo, selezionare la voce di menu Read|NTFS Attribute, che apre un'altra finestra di dialogo. DiskEdit fa distinzione tra maiuscole e minuscole, quindi immettere il codice seguente esattamente come l'ho elencato:
Base Frs Number: 5
Base Frs (Base File Record Segment) è un altro nome del numero MFT. Immettere 5 per specificare che si vuole leggere un attributo dalla directory radice.
Attribute Type: $INDEX_ALLOCATION
Indica a DiskEdit che si vogliono leggere i dati del contenuto della directory. È consigliabile usare il menu a discesa per scegliere l'attributo desiderato perché DiskEdit è molto esigente sulla modalità di immissione del tipo di attributo.
Attribute Name: $I30
Se si visualizza l'attributo $INDEX_ALLOCATION della directory radice, si noterà che "$I30" è elencato come nome nella riga "Type code, name", quindi è ciò che si immette come nome dell'attributo.
Premere OK e verrà visualizzato un dump esadecimale del contenuto dell'attributo. Si vuole esaminare qualcosa di più comprensibile, quindi selezionare la voce di menu View|NTFS Index Buffer. Verrà visualizzato l'elenco dei contenuti della directory. Scorrere l'elenco fino a visualizzare la voce con il nome "TEMP". Se non è visibile, la voce potrebbe trovarsi nell'attributo $INDEX_ROOT della directory radice, un tipo di attributo associato anche alle directory e che ha sempre il relativo valore archiviato nel record MFT. Le voci radice dell'indice e le voci di allocazione formano insieme una struttura ad albero B+ che archivia tutte le voci di una directory. Se è necessario visualizzare l'attributo $INDEX_ROOT, seguire la stessa procedura usata per visualizzare l'attributo $INDEX_ALLOCATION. Quando si scorre un buffer di indice, è possibile che si notino due righe di asterischi: questi designano la fine di un buffer di indice e l'inizio del successivo.
Dopo aver trovato la voce della directory TEMP prendere nota del relativo file reference (FRS). Selezionare Read|NTFS File Record e immettere l'FRS di TEMP. A questo punto è visibile il record MFT per la directory TEMP. Si vuole trovare il file OUT.TXT, quindi è necessario esaminare il contenuto di TEMP per trovarlo. Visualizzare l'attributo $INDEX_ALLOCATION o $INDEX_ROOT della directory TEMP, passare alla visualizzazione dei dati come buffer di indice NTFS e individuare il file OUT.TXT. Ricordarsi di immettere FRS di TEMP come numero di base FRS nella finestra di dialogo di selezione degli attributi. Se è stato appena creato TEMP, avrà solo un oggetto $INDEX_ROOT. Se si digita in modo errato si avrà il piacere di vedere una delle finestre di dialogo di errore vuote di DiskEdit.
Dopo aver trovato OUT.TXT e determinato il suo FRS, usare Read|NTFS File Record per esaminare la relativa voce MFT. Scorrere verso il basso fino a trovare l'attributo $DATA. A questo punto è visibile la posizione dei dati di OUT.TXT. Poiché è stato creato un file di piccole dimensioni, i dati vengono archiviati nel record MFT. Se si prova a visualizzare l'attributo $DATA di OUT.TXT usando DiskEdit non si vedrà nulla, dato che DiskEdit non mostra correttamente i dati residenti (uno dei numerosi bug di DiskEdit). Copiare quindi un file di testo abbastanza grande (> 2 kB) in \TEMP\ OUT.TXT. È ora possibile visualizzare i dati di OUT.TXT in uno dei due modi seguenti: esaminare l'inizio dei dati (o tutti i dati se sono archiviati in modo contiguo sul disco) usando Read|NTFS Cluster e specificando il primo valore "lcn" visualizzato nell'attributo $DATA di OUT.TXT "Extent List"; oppure usare Read|NTFS Attribute e immettere "$DATA" come tipo di attributo e nulla (non digitare nulla in quel campo) come nome dell'attributo.
Gli elenchi di estensione descrivono la posizione dei dati non residenti di un attributo. Ogni blocco contiguo di dati di lunghezza fino a 16 cluster è descritto da una voce dell'elenco di estensione. Una voce dell'elenco di estensione specifica un numero di cluster virtuale (vcn), un numero di cluster logico (lcn) e una lunghezza di esecuzione. Un Vcn è il cluster all'interno del file in cui iniziano i dati descritti dalla voce. Un Lcn designa il cluster logico in cui i dati sono archiviati sul disco e la lunghezza di esecuzione è il numero di byte dei dati dell'attributo in quella posizione. Tenere presente che DiskEdit mostra valori esadecimali.
Ho illustrato la strada più lunga per trovare il record MFT del file OUT.TXT, mostrando come analizzare il contenuto della directory. Esiste tuttavia una scorciatoia: selezionare Crack|NTFS Path e inserire TEMP\OUT.TXT. Verrà visualizzato l'FRS di OUT.TXT ed è possibile usare Read|NTFS File Record per passare direttamente a esso.
Questo mi porta alla fine della mia introduzione a DiskEdit. Vi invito a giocare con questo abile strumento sfogliando le unità FAT o NTFS. È molto improbabile che si trovi l'occasione di usare DiskEdit per modificare i dati al fine di risolvere i problemi del disco, ma se si è curiosi del formato NTFS su disco (il formato FAT è ben documentato) questo è lo strumento perfetto per l'analisi.
SVILUPPI FUTURI
ESPLOSIONE DELL'API DI WIN2K
Anche se sono presenti solo 4 nuove API esportate in modalità kernel che hanno fatto il loro debutto in RC2, il numero totale di API introdotte da Microsoft a partire da NT 4.0, sia nel kernel che nelle DLL Win32 core, è esploso. Il mese prossimo vi dirò esattamente quante nuove API ci sono e dove sono apparse, e allo stesso tempo darò alle persone che credono che Win2K sia un mostro enorme alcune ottime munizioni per le problematiche relative alla Usenet alt.advocacy.linux.
Grazie per aver letto la newsletter Systems Internals.
Pubblicata da ottoh mercoledì 20 ottobre 1999 alle 18:10
[Archivio newsletter ^] [< Volume 1, Numero 4] [Volume 2, Numero 1 >]