• Cikk

[Hírlevelek archívuma ^][< 1. kötet, 4. szám][2. kötet, 1 >. szám ]

The Systems Internals Newsletter Volume 1, Number 5

http://www.sysinternals.com
Copyright 1999 Mark Russinovich

1999. október 12. – Ebben a kérdésben:

  1. A SYSTEMS INTERNALS ÚJDONSÁGAI

    • NTFS for Windows 98/NTFSDOS Professional
    • DebugView v3.21
    • Filemon és Regmon v4.21
    • Diskmon v1.1
    • Systems Internals at www.microsoft.com
    • Októberi "NT Internals"
    • Nem annyira új dolgok

  2. BELSŐ HÍREK

    • Megjelent a Win2K RC2 DDK
    • Új Win2K RC Kernel API-k
    • Szoftverfejlesztés '99 Kelet
    • A DiskEdit használata

  3. MI VÁRHATÓ?

    • Win2K API-robbanás

SZPONZOR: WINTERNALS SZOFTVER

A Systems Internals Hírlevél által szponzorált Winternals Software, a weben a http://www.winternals.com. A Winternals Software a Windows NT/2K fejlett rendszereszközök vezető fejlesztője és szolgáltatója. A Winternals szoftvertermékek közé tartozik a FAT32 a Windows NT 4.0-hoz, az ERD Commander (a Windows NT rendszerindító lemezes képessége) és az NTRecover.

A Winternals Software távoli helyreállítása lehetővé teszi, hogy a vállalat bármely pontjáról tcp/IP-címen keresztül elérhesse a ki nem kapcsolható számítógép meghajtóit. Időt és támogatást takaríthat meg azáltal, hogy távolról kijavítja az NT- vagy Win9x-rendszereket érintő illesztőprogram-, fájlrendszer- és konfigurációs problémákat. Akár távoli chkdsk- vagy particionálási műveleteket is végrehajthat a Remote Recovery használatával, ami sokoldalú vészhelyreállítási eszköz. Töltsön le egy ingyenes írásvédett próbaverziót a következő címen http://www.sysinternals.com/rrecover.htm, és vásárolja meg az olvasási/írási verziót: http://www.winternals.com.

Üdvözlök mindenkit!

Üdvözöljük a Systems Internals hírlevélben. A hírlevélnek jelenleg 10 000 előfizetője van.

A Windows 2000 (Win2K) kiadása úgy tűnik, hogy követi a küszöbön álló, majd visszatolt mintát. A legújabb pletykák szerint februárban elérhetővé válik. A Win2K szállítási dátumával kapcsolatos egyetlen információ a pletykákban van, mivel a Microsoft nem is mondja el az oem-eknek vagy partnereknek, hogy mikor szállítja. Nos, ezek a következők: "akkor száll, amikor készen áll" (nem kényszerítem a dátumos mondást arról, hogy bort árulunk itt).

Az irritáló dolog a Microsoft, hogy a sajtó által generált a termékek mindig teszi úgy tűnik, mintha a szélén a szállítás még akkor is, ha a termékek vaporware. A legújabb példa a Millennium, a Windows 98 utódja. A Microsoft nem túl régen nagy lökést adott a sajtónak, mintha kész termék lenne, készen áll arra, hogy az összes háztartási készüléket intelligens eszközökké alakítsa. Az iróniát az, hogy a cikkek rövid idő múlva kiderült, hogy a Microsoft még nem is definiálta teljesen a terméket, és valószínűleg egy vagy több év lesz, mielőtt a boltok polcain látnánk.

Ez a minta nem új, és nem én vagyok az első, aki írni róla. De ez nem akadályozza meg, hogy spekuláljon, hogy mennyi a see-sawing egy gondosan vezényelt terv, és mennyi az eredménye a teljes hiánya szoftvermérnöki tagok. Ha vásárol a korábbi szögben, mint az összeesküvés-elméletek, a Microsoft briliánsan megfojtja a versenyt tantalizing ügyfeleket, hogy a hihetetlen termék, hogy ha várnak csak egy kicsit tovább, hogy a várakozás érdemes, és minden szükséges, hogy forduljon egy nem Microsoft-termék. Az utóbbi szög azt mondja, hogy a Microsoft soha nem fogja megtanulni a szoftverfejlesztési folyamatot, és folyamatosan alábecsüli a mérnöki erőfeszítéseket, és túlbecsüli a béta kód minőségét.

A kerítésen ülök, hogy melyik elmélethez írok. Azt hiszem, a minta egy kicsit mindkettőnek köszönhető. Úgy gondolom, hogy ez segített a Microsoftnak, hogy úgy viselkedjen, mintha az Active Directory már két éve majdnem készen áll. Bizonyára vannak olyan ügyfelek, akik már régen a Novell Directory Serviceshez fordultak volna, ha előre tudták volna, hogy mennyi ideig kellene várniuk a Win2K-ra. Másrészt a Microsoft ismételt fekete szemeket kapott a sajtóban az ígéretes termékkézbesítéstől, majd a késleltetéstől. Úgy gondolom, hogy a Microsoft vezetősége egyszerűen nem érti, milyen nehéz reprodukálni, elkülöníteni és kijavítani a hibák utolsó 5%-át.

A Microsoft fejlesztési gyakorlatáról szólva a kiadás előtti elnevezési sémájuk az egyik leginkább zavarba ejtő, amit láttam. Bétaverziójuk valóban alfa, és a kiadási jelöltjeik valójában bétaverziók. És még ezeknek a definícióknak a használata is egy szakasz: a Microsoftnak nem okoz problémát a funkciók bemásolása a szoftverből az egyik kiadási jelöltről a következőre való ugráskor, vagy akár újak hozzáadásában. Ezt az NT 4.0-val tették, és a Win2K-val csinálják. Ez a gyakorlat természetesen nem felgyorsítja a kiadási ciklust.

És a Win2K februárban szállít? Azt hiszem, az alagút végén látjuk a fényt. Végül is csak néhány új API van az RC2-ben...

Az utolsó hírlevél folytatásaként, ahol a Microsoft rövidítési zavarairól beszéltem, George Janczuk olvasó talált egy másik példát. A "Kiterjesztve a nagyszámítógép tranzakciófeldolgozási világára" című szakaszban a cikk http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm a CISC – Komplex utasításkészlet-számításra hivatkozik. A nagyszámítógépes alkalmazásokban jártas felhasználók számára nyilvánvaló, hogy a tervezett betűszó a CICS – Customer Information Control System. Fordított betűsor, és teljesen más technológiai területen vagy.

Mint általában, kérjük, adja át a hírlevelet a barátok, hogy úgy gondolja, lehet, hogy érdekes.

Köszönjük!

-Mark

A SYSTEMS INTERNALS ÚJDONSÁGAI

NTFS FOR WINDOWS 98/NTFSDOS PROFESSIONAL

Végre megtettük. Amióta Bryce és én megjelent NTFSDOS 1.0 vissza a spring of 1996 már keres a szent grál a Windows fájlrendszer kompatibilitás: olvasási / írási hozzáférés NTFS a Windows 9x és DOS. Már régen megállapítottuk, hogy az NTFS formátum megfordítása és az illesztőprogram írása ehhez az összetett naplózási fájlrendszerhez nehéz és kockázatos javaslat lenne. Még ha pontosan meghatározza is a formátum minden árnyalatát, a formátum frissítése, például a Win2K NTFS 5.0-s verziójának frissítése teljesen új fordított tervezést és fejlesztést igényel. Emellett a fájlrendszer-illesztő helyességének ellenőrzése olyan bonyolult formátumra, mint az NTFS esetében, ijesztő javaslat.

Ezért csaltunk.

A Windows 98-hoz készült NTFS teljes olvasási/írási hozzáférést biztosít az NTFS-meghajtókhoz Windows 95-ből vagy Windows 98-ból, az NTFSDOS Professional pedig teljes NTFS olvasási/írási hozzáférést biztosít a DOS-ból. Sem a Windows 98-hoz készült NTFS, sem az NTFSDOS Professional nem ismeri az NTFS fájlrendszer formátumát. Ehelyett a Windows NT- vagy Windows 2000-telepítés NTFS-illesztőprogramjára támaszkodnak a tudás implementálásához. Mindkét segédprogram ugyanazt a kódbázist használja, amely az NTFS fájlrendszer-illesztőprogram környezetburkolójaként szolgál. A Windows 98-hoz készült NTFS a Windows 9x fájlrendszer API-hoz biztosít interfészt az NTFS fölött, valamint az NTFS alatti Windows 9x lemezszolgáltatásokhoz. A Windows 98-hoz készült NTFS felület az NTFS natív Windows NT/2K-környezetéhez hasonlóan jelenik meg, kiegészítve az INTEGRÁCIÓS MODULOKKAL, az I/O Managerrel, a Cache Managerrel, az NT-stílusú lemezeszközökkel és az NTFS által használt egyéb NT/2K-alrendszerekkel.

Az NTFSDOS Professional ugyanúgy működik, mint a Windows 98-hoz készült NTFS, azzal a különbségtel, hogy az NTFS-et a fenti DOS-szolgáltatásokhoz és az alábbi BIOS Interrupt 13 lemezszolgáltatáshoz illeszti. Az NT/2K-szerű környezet létrehozásához számos függvényre támaszkodunk az NTOSKRNL-ben, az NT/2K kernelfájlban. Mindkét segédprogram betölti az NTOSKRNL-t az NTFS-szel együtt, így az NTFS közvetlenül használhatja a kernel natív szolgáltatásait.

Annyira szórakoztató volt az NTFS-környezet létrehozása, hogy egy lépéssel tovább mentünk: ugyanezt tettük az NT rendszerindítási idejének chkdsk segédprogramjával, az Autochk-tal is. A Windows 98-hoz készült NTFSDOS Professional és NTFS fájlrendszerhez ntfs chkdsk segédprogram érhető el NTFSCHK néven. Az NTFSCHK ugyanazon a néven működik, mint az NTFS fájlrendszer burkolója, ahol NT-szerű környezetet hoz létre az Autochk programhoz, hogy az Autochk a Windows 95/98 és a DOS alatt fusson. Ennek a trükknek az eredménye a Windows 95/98 és a DOS teljes NTFS olvasási/írási támogatása.

A Windows 98-hoz http://www.sysinternals.com/ntfs98.htm készült NTFS ingyenes írásvédett verzióját és az NTFSDOS Professional ingyenes írásvédett verzióját a következő címen töltheti le: http://www.sysinternalscom/ntfspro.htm. Mindkét eszköz teljes olvasási/írási verzióját megvásárolhatja a Winternals Software- http://www.winternals.com.

DEBUGVIEW V3.21

A DebugView egy hibakeresési kimenetű monitor, amely a Kernel és a Win32 hibakeresési kimenetét is rögzíti a Windows 95, a Windows 98, az NT 4.0 és a Windows 2000 rendszerben. Speciális szűrési, kiemelési és naplózási képességekkel rendelkezik, és akár a hálózaton keresztüli rendszer hibakeresési kimenetét is rögzítheti. A legújabb, 3.21-es kiadás lehetővé teszi a 16 bites OutputDebugString kimenet figyelését a Windows 95 és a Windows 98 rendszerben.

A DebugView 3.21-et a http://www.sysinternals.com/dbgview.htm.

FILEMON ÉS REGMON V4.21

A Filemon és a Regmon a Windows 95, 98, NT 4.0 és Win2K fájlrendszer- és beállításjegyzék-kémelési segédprogramja. Továbbra is fejlődnek az új használhatósági funkciókkal, és a 4.21-es kiadással (a Filemon és a Regmon szinkronizált verziószámokkal rendelkezik) fejlettebb szűrést vezetnek be a legutóbbi szűrőlistákkal, a kiemelési szűrő definiálásának lehetőségét (egyéni színekkel is), testre szabható betűtípust, vágólap-támogatást és több CUI-kompatibilis gyorsbillentyűt. Az illesztőprogram forráskódját is átdolgozták, és robusztusabb paraméterérvényesítést tartalmaz a GUI-interface függvényekben.

Töltse le a Filemon v4.21 at http://www.sysinternals.com/filemon.htm és a Regmon v4.21 at http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

A Diskmon egy olyan eszköz, amely figyeli és megjeleníti a logikai és fizikai lemeztevékenységet. Az 1.1-es verzió frissíti a Diskmonot a Windows 2000-es verzióval való együttműködéshez, és új használhatósági fejlesztéseket vezet be. Emellett a Diskmon most már számos lemez- és tömegtároló I/O-vezérlőkódot értelmez, és a hexadecimális kódokat szövegábrázolásokra fordítja a Diskmon kimeneti ablakban.

A Diskmon v1.1 nem csak lemezfigyelőként működik, de szoftveralapú lemezfényként is használható. Ha lemezfényes módban állítja be, a Diskmon kis méretűre csökkenti magát a rendszertálcában, mivel a lemez olvasási hozzáférése zöld, a lemez írási hozzáférése pedig piros.

Diskmon v1.1 letöltése a http://www.sysinternals.com/diskmon.htm.

BELSŐ RENDSZEREK WWW.MICROSOFT.COM

Figyelembe véve a Systems Internals (korábbi nevén NT Internals) előzményeit, nagy hízelgő, hogy a Microsoft sysinternals.com hivatkozik erőforrásként az ügyfelei számára. Egyre több Microsoft Tudásbázis-cikk mutat a Systems Internals segédprogramokra. Íme a legújabbak:

  • Q183060 INFORMÁCIÓ: Hibaelhárítási útmutató 80004005 & egyéb hibaüzenetekhez http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    Ez a cikk azt ismerteti, hogy a Filemon segítségével ellenőrizheti az OLE DB, az ActiveX-adatobjektumok és a távoli adatszolgáltatás adatelérési hibáinak okát.

  • Q196453 – Az NTVDM és a WOW indítási hibáinak elhárítása http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Ez a cikk arra is rámutat, hogy a Filemon olyan eszköz, amely meghatározza, hogy mely hiányzó fájlok okoznak indítási hibákat az NTVDM-hez (az NT Win16/DOS kompatibilitási környezetéhez).

  • Q216368 – PRB: Hozzáférés megsértése az alkalmazás beállítása során, amikor a fájl használatban van http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    A HandleEx és a DLLView ajánlott eszközök a Visual Basic Telepítővarázsló és a Telepítővarázsló által létrehozott telepítőprogramok végrehajtása során előforduló hibák okának meghatározásához.

  • Q232830 – ÚTMUTATÓ: A fájlkezelő tulajdonjogának meghatározása http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    A HandleEx ismét lekéri a jelen cikkben szereplő javaslatot, amely ismerteti, hogy milyen folyamat van megnyitva egy fájllal vagy könyvtárral.

OKTÓBERI "NT INTERNALS"

Az "NT Internals" oszlopom a Windows NT Magazine októberi számában a következő: "Inside Win2K Reliability Enhancements, Part 3". A háromrészes sorozat harmadik része két hatékony Win2K-funkciót ír le, amelyek segítenek a fejlesztőknek és a rendszergazdáknak a hibás illesztőprogramok rögzítésében: az írásvédett kernelmemória és az Illesztőprogram-ellenőrző.

Az orosz olvasók most már anyanyelvükön olvashatják a cikkeimet. Lépjen át a Windows NT Magazine orosz kiadásához, http://www.osp.ru/win2000/ és nézze meg az első lefordított NT Internals oszlopot a rendszerindítási folyamaton belül (http://www.osp.ru/win2000/1999/10/59.htm). Köszönöm Ivan Rouzanovnak, hogy tájékoztatott erről.

Augusztus elejétől a Windows NT Magazine-cikkek online verziói csak az előfizetők számára érhetők el, és a cikkek minden új problémával online jelennek meg. Ha még nem iratkozott fel, a Systems Internals előfizetési kedvezményének beszerzéséhez lépjen az előfizetés hivatkozására http://www.sysinternals.com/publ.htm .

NEM ÚJ DOLGOK

A WinObj egy hatékony eszköz a Windows NT/2K objektumnévtér felderítéséhez. Az objektumnévtér az NT/2K három névterének egyike: az objektumnévtér, a beállításjegyzék-névtér és a fájlrendszer névtere. A beállításjegyzék és a fájlrendszer névterei az Objektum névtérben lévő objektumokon keresztül jutnak el. Ha például egy Win32-program megnyitja a Beállításkulcsot HKEY_LOCAL_MACHINE\Software\Microsoft , a ADVAPI32.DLL kódtár átalakítja a nevet \Registry\Machine\Software\Microsoft a kernelszolgáltatás NtCreateKeymeghívása előtt. Ha megtekinti a WinObj objektumnévterének gyökerét, megjelenik egy beállításjegyzék nevű "kulcs" típusú objektum. A beállításjegyzék neve megegyezik a kulcsnév első összetevőjével, \Machine\Software\Microsoftígy az NT/2K Object Manager átadja a név többi részét a kulcsobjektumot meghatározó alrendszernek. A Configuration Manager kernel-alrendszere fenntartja a beállításjegyzéket és a kulcsobjektumokat, így a név többi részét elemzi a kívánt kulcs megkereséséhez.

Megismerheti az objektumnévteret, és megtekintheti vagy beállíthatja az objektumbiztonsági tulajdonságokat a WinObj használatával. Winobj letöltése: http://www.sysinternals.com/winobj.htm. Az Object Manager névterét és a WinObj-t az 1997. Kövesse az oszlop on-line verziójára mutató hivatkozást a következő címen: http://www.sysinternals.com/publ.htm.

BELSŐ HÍREK

WIN2K RC2 DDK RELEA Standard kiadás D

A Microsoft Eszközillesztő-fejlesztőkészletének (DDK) Win2K RC2 kiadását a következő címen töltheti le: http://www.microsoft.com/ddk/ddkRC2.htm. A készletet ingyenesen letöltheti, vagy a dokumentációt online böngészheti.

ÚJ WIN2K RC2 KERNEL APIS

A dolgok a legújabb Win2K-kernelben stabilizálva jelennek meg. Az RC3-ban csak négy új, exportált kernel API található, szemben a 3. bétaverzióból az RC1-be került körülbelül egy tucat megjelent (és egy másik fél tucat, amely eltűnt). Számos új funkció kissé érdekes, ezért úgy döntöttem, hogy dokumentálja őket az Ön számára. Az első, MmGetSystemRoutineAddressés bár még nem dokumentálták, a prototípus szerepel az RC2 DDK ntddk.h fejlécfájljában:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

A használata ugyanolyan egyszerű, mint amilyennek látszik. Adja meg egy olyan függvény nevét, amely NTOSKRNL.EXE vagy HAL.DLL található, és vissza fogja kapni a belépési pont címét. Ez a függvény valójában haszontalan a Win2K első kiadásában, de az út során nagyon hasznos lehet, és a Microsoftnak szerepelnie kellett volna az NT első kiadásában (3.1). A Win32-alkalmazások felhasználói felületéhez hasonlóan GetProcAddress ez a függvény lehetővé teszi, hogy az illesztő dinamikusan megállapítsa az API rendelkezésre állását. Ha a Microsoft új API-kat ad hozzá a Win2K-szervizcsomagokhoz (és biztos vagyok benne, hogy lesznek), az illesztőprogramok írhatók az API-k előnyeinek kihasználásához, de a Win2K régebbi verzióiban is, vagy olyan módban való futtatáshoz, ahol nem használják az API-kat. Az illesztőprogramnak az a kulcsa, hogy ezt meg tudja tenni, az API-k jelenlétének ellenőrzése a betöltés után. E funkció nélkül az illesztőprogramnak statikusan kell kapcsolódnia az általa használt függvényekhez, és ha a függvények nem jelennek meg az illesztőprogram betöltésekor, akkor a kernelbetöltő csúnya hibát jelent a felhasználónak, és nem tudja betölteni az illesztőprogramot.

A második új API a MmGetPhysicalMemoryPages. A prototípus az RC2 ntddk.h-ban található, de nem dokumentált. Prototípusa:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Hol PHYSICAL_MEMORY_RANGE található:

typedef struct _PHYSICAL_MEMORY_RANGE {
    PHYSICAL_ADDRESS BaseAddress;
    LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;

Ez a függvény egy olyan bejegyzéstömböt PHYSICAL_MEMORY_RANGE ad vissza, amelynek végén a tömb egy olyan bejegyzéssel van megjelölve, amely mind a kettőhöz BaseAddress 0, mind NumberOfBytespedig 0 értéket tartalmaz. Ez MmGetSystemRoutineAddressegy elég egyszerű API. Visszaadja a Win2K által ismert összes fizikai memória leírását. A Win2K támogatja a memória hozzáadását és eltávolítását menet közben az MmAddPhysicalMemory API-kkal MmRemovePhysicalMemory . Ez motiválja egy olyan API meglétének okát, amely lehetővé teszi a memóriatartományok lekérdezését. MmAddPhysicalMemory rc1-ben és MmRemovePhysicalMemory RC2-ben lett hozzáadva. Mindkét függvény prototípusa az ntddk.h.

Mik a többi új RC2 API-k? PoShutdownBugCheck és RtlInvertRangeList. PoShutdownBugCheck lehetővé teszi a rendszer összeomlását, és végrehajthat egy áramellátással kapcsolatos műveletet, például a felfüggesztést. Az RC2 kernel néhány helyen használja. A tartományok általános kezdő end-specifikációk, amelyeket számos kernel API támogat a felhasználók által definiált és felügyelt, rendezés és iterálás céljából. A Win2K Plug-and-Play erőforrás-arbiterei a hardvererőforrás-követelmények nyomon követésére és rendszerezésére használják őket. Annak ellenére, hogy a tartománylista API-k nincsenek dokumentálva, az összes prototípus és struktúradefiníció az ntddk.h része, így feltehetően használhatja az API-t a saját start-end-orientált adatok kezelésére.

A későbbi hírlevelekben a nem dokumentált API-k még szórakoztatóbbak lesznek.

SZOFTVERFEJLESZTÉS 99 KELET

A Szoftverfejlesztés 1999-ben megjelent keleti parti kiadása November 8-12. között Washingtonban kerül megrendezésre. Az elmúlt napon három előadást tartok: a Windows 2000 for Developers újdonságai, a Windows NT/2000 Kék képernyő és a Windows NT/2000 hálózatkezelés újdonságai. Ezen kívül, Dave Solomon, szerzője Inside Windows NT 2nd Edition és egy szomszéd (él mindössze 20 percre tőlem, minden helyen, Danbury, CT), és én üzemelteti a Windows NT/2K belső kerekasztal. Együtt fogunk válaszolni a Windows NT/2K belső rendszereivel kapcsolatos legkeményebb kérdéseire. Köszönj és említsd meg a hírlevelet, és adok neked egy ingyenes Systems Internals pólót!

Keresse fel a szoftverfejlesztési webhelyet a következő címen: http://www.sdexpo.com.

A DISKEDIT HASZNÁLATA

Lehet, hogy nem tudja, de van egy lemezszerkesztő segédprogram a Windows NT-hez a dos-hoz készült, megbízható Norton Disk Edit stílusában. Mi több, a segédprogram megérti a FAT és az NTFS, és ez ingyenes. A Microsoft nyilvánvalóan véletlenül szállította a DiskEdit eszközt, amely a Windows NT 4.0 Service Pack 4 CD-n belső hibakereső eszköznek kell lennie a fájlrendszer-csapatok számára. A DiskEditnek van egy sajátos felülete, amely egy kis kézikönyvet hozna létre a dokumentumhoz, de egy egyszerű útmutatóval fogom kezdeni. A DiskEdit használatával oldom fel az NTFS fájlrendszer formátumát, mivel a DiskEdit az egyetlen nyilvánosan elérhető eszköz, amelyről tudom, hogy ismeri az NTFS-t.

Először le kell kérnie a DiskEditet a Service Pack 4 (SP4) CD-ROM-ról. Egyszerűen másolja az \i386 könyvtárból a merevlemezre. Ha a DiskEditet a Win2K alatt szeretné használni, létre kell hoznia egy privát könyvtárat, és a következő DLL-eket egy SP4 winnt\system32 könyvtárból (vagy SP4 CD-ből) a DiskEdittel megegyező könyvtárba kell másolnia: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL és UFAT.DLL. Most már elindíthatja a DiskEditet.

Ehhez az útmutatóhoz hozzon létre egy TEMP nevű könyvtárat egy NTFS-meghajtó gyökerénél, és hozzon létre egy OUT.TXT nevű fájlt abban a könyvtárban. Ehhez írja be a következő parancsot egy parancssori ablakban, amelyben a TEMP az aktuális könyvtár: echo hello > out.txt. Válassza ki az új OUT.TXT fájlt tartalmazó meghajtót a DiskEditben a Fájl|Nyissa meg a menüelemet, és írja be a meghajtó betűjét az eredményként kapott párbeszédpanel Kötetnév mezőjébe. Győződjön meg arról, hogy tartalmazza a kettőspontot, például "d:". A DiskEdit szinte minden funkciójának használatához meg kell nyitnia egy meghajtót.

Megkeressük a OUT.TXT fájlt az NTFS-meghajtó gyökérkönyvtárától kezdve. Válassza ki az Olvasás| menübejegyzéstNTFS-fájlrekord egy párbeszédpanel megnyitásához, amely lehetővé teszi az MFT rekordbejegyzések megtekintését csak a szám megadásával. Minden NTFS-meghajtó első 16 MFT rekordbejegyzése fenntartott, és megfelel az előre definiált NTFS metaadatfájloknak. Íme a szám-hozzárendelések (vegye figyelembe, hogy a DiskEdit az összes bemenetet hexadecimálisként értelmezi):

        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)

Tekintse meg ezeket az MFT-bejegyzéseket. Ekkor megjelenik egy gyakori téma: ezek mindegyike olyan attribútumokból áll, mint a $INDEX_ROOT, $FILE_NAMEés $DATA. Olyan attribútumokban található, amelyekben egy fájlra jellemző adatok vannak tárolva. Ha az attribútumadatok kicsik, az NTFS a fájl MFT rekordjában lévő adatokat "rezidens" adatokként tárolja, és ha az adatok nagyok, az NTFS a lemezen lévő fürtökben a rekordon kívüli adatokat "nem rezidens" adatokként tárolja.

Most adja meg az "5" értéket a fájlszámként, és a gyökérkönyvtár fájlját fogja megtekinteni. A gyökérkönyvtárban található fájlokat és könyvtárakat a címtár attribútumának $INDEX_ALLOCATION megtekintésével tekintjük meg, amely a címtár tartalmát tároló könyvtárakra jellemző attribútum. Ehhez válassza az Olvasás|NTFS Attribútum menübejegyzés, amely egy másik párbeszédpanelt nyit meg. A DiskEdit érzékeny a kis- és nagybetűkre, ezért pontosan adja meg a következőket, ahogy felsoroltam:

        Base Frs Number: 5

A Base Frs (alapfájlrekordszegmens) az MFT-szám másik neve. Adja meg az 5 értéket, és adja meg, hogy be szeretne olvasni egy attribútumot a gyökérkönyvtárból.

        Attribute Type: $INDEX_ALLOCATION

Ez azt jelzi a DiskEditnek, hogy be szeretné olvasni a címtár tartalomadatait. Azt javaslom, hogy a lekéréses menüvel válassza ki a kívánt attribútumot, mivel a DiskEdit nagyon válogatós az attribútumtípus megadásának módjáról.

        Attribute Name: $I30

Ha megtekinti a $INDEX_ALLOCATION gyökérkönyvtár attribútumát, látni fogja, hogy a "$I30" név szerepel a "Type code, name" sorában, így ezt adja meg attribútumnévként.

Nyomja le az OK billentyűt, és megjelenik az attribútum tartalmának hexadecimális memóriaképe. Valami érthetőbbet szeretnénk látni, ezért válassza a Nézet|NTFS indexpuffer menübejegyzés. Ekkor megjelenik a könyvtár tartalmának felsorolása. Görgessen végig a listaelemen, amíg meg nem jelenik a "TEMP" nevű bejegyzés. Ha nem látja, előfordulhat, hogy a bejegyzés a gyökérkönyvtár $INDEX_ROOT attribútumában található, egy címtárakhoz is társított attribútumtípus, és amelynek értéke mindig az MFT rekordban van tárolva. Az indexgyökerű bejegyzések és a foglalási bejegyzések együttesen egy B+ fastruktúrát alkotnak, amely egy könyvtár összes bejegyzését tárolja. Ha meg kell tekintenie az $INDEX_ROOT attribútumot, kövesse az attribútum megtekintésének ugyanazokat a lépéseit, mint az $INDEX_ALLOCATION attribútum megtekintéséhez. Amikor végiggörget egy indexpufferen, két csillagsorra léphet: ezek jelölik az egyik indexpuffer végét és a következő elejét.

Miután megtalálta a TEMP könyvtár bejegyzését, jegyezze fel annak fájlhivatkozását (FRS). Válassza az Olvasás| lehetőségetNTFS-fájlrekord, és adja meg a TEMP frS-jét. Most a TEMP könyvtár MFT rekordját vizsgáljuk meg. Meg szeretnénk keresni a OUT.TXT fájlt, ezért a temp tartalmát át kell vizsgálnunk, hogy megtaláljuk. Tekintse meg a $INDEX_ALLOCATION TEMP könyvtár (vagy $INDEX_ROOT) attribútumát, váltson át az adatok NTFS indexpufferként való megtekintésére, és keresse meg a OUT.TXT fájlt. Ne felejtse el megadni a TEMP FRS-jét alap FRS-számként az attribútumkijelölési párbeszédpanelen. Ha most hozta létre a TEMP-t, akkor az csak egy $INDEX_ROOT lesz (ha elgépel valamit, örömmel láthatja a DiskEdit üres hibaablakait).

Amikor megtalálta a OUT.TXT és meghatározta annak FRS-jét, használja a Read|NTFS-fájlrekord az MFT-bejegyzés megtekintéséhez. Görgessen lefelé, amíg meg nem találja a $DATA attribútumot. Most a OUT helyét vizsgáljuk. TXT-adatok. Mivel kis fájlt készítettünk, az adatok az MFT rekordban lesznek tárolva. Ha a OUT nézetet próbálja megtekinteni. A TXT DiskEditet használó attribútuma $DATA semmit sem fog látni, mivel a DiskEdit nem jeleníti meg megfelelően a rezidens adatokat (a DiskEdit számos hibája egyike). Ezért másolja a largish (> 2KB) szövegfájlt a fájlba \TEMP\ OUT.TXT. Most kétféleképpen tekintheti meg a OUT.TXT adatokat: a Read| használatával megvizsgálhatja az adatok kezdetét (vagy az összeset, ha azok egybefüggően a lemezen találhatók).NTFS-fürt, és adja meg az első "lcn" értéket, amely a OUT-ben jelenik meg. TXT attribútuma $DATA "Extent List"; vagy használhatja a Read|NTFS-attribútum, és attribútumtípusként adja meg a "$DATA" értéket, az attribútum neveként pedig semmit (például ne írjon be semmit ebbe a mezőbe).

A mértéklisták egy attribútum nem rezidens adatainak helyét írják le. Az egybefüggő, legfeljebb 16 fürt hosszúságú adatblokkokat egy mértéklista-bejegyzés ismerteti. A mértéklista-bejegyzés megadja a virtuális fürt számát (vcn), a logikai fürt számát (lcn) és a futtatás hosszát. A Vcn az a fürt abban a fájlban, amelyben a bejegyzésben leírt adatok elindulnak. Az Lcn kijelöli azt a logikai fürtöt, ahol az adatok lemezen vannak tárolva, a futási tartomány pedig az adott helyen található attribútumadatok bájtjainak száma (ne feledje, hogy a DiskEdit hexadecimális értékeket jelenít meg).

Végigvezettem a OUT.TXT fájl MFT rekordjának megkeresésének hosszú útján, bemutatva, hogyan vizsgálhatja a könyvtár tartalmát. Van azonban egy parancsikon: válassza a Crack|NTFS-elérési út, és írja be a TEMP\OUT.TXT értéket. Megjelenik a OUT. TXT-fájl frS-jét, és használhatja a Read|NTFS-fájlrekordot, hogy jobbra lépjen hozzá.

Ezzel a DiskEdit-alapozóm végére érek. Azt javasoljuk, hogy játsszon ezzel a remek eszközzel a FAT- vagy NTFS-meghajtók böngészésével. Nagyon valószínűtlen, hogy valaha is talál alkalmat arra, hogy a DiskEdit használatával módosítsa az adatokat annak érdekében, hogy a lemezt kihúzza egy elakadásból, de ha kíváncsi a lemezen lévő NTFS formátumra (a FAT formátum jól dokumentált), ez a tökéletes eszköz a vizsgálathoz.

MI VÁRHATÓ?

WIN2K API-ROBBANÁS

Bár csak 4 új exportált, kernel módú API jelent meg az RC2-ben, a Microsoft által az NT 4.0 óta bevezetett összes API-k száma, mind a kernelben, mind az alapvető Win32 DLL-ekben, felrobbant. Jövő hónapban elmondom, hogy pontosan hány új API-k vannak, és hol jelentek meg, és sajnos ugyanakkor, hogy az emberek úgy vélik, hogy a Win2K egy puffadt szörny néhány nagy lőszer az alt.advocacy.linux Usenet rants.

Köszönjük, hogy elolvasta a Systems Internals Hírlevél.

Közzétéve: 1999. október 20. szerda, 19:10

[Hírlevelek archívuma ^][< 1. kötet, 4. szám][2. kötet, 1 >. szám ]