[Archivo de boletines ^] [< Volumen 1, Número 4] [Volumen 2, Número 1 >]
Boletín de información interna de sistemas Volumen 1, Número 5
http://www.sysinternals.com
Copyright 1999 Mark Russinovich
12 de octubre de 1999: en este número:
NOVEDADES DE SYSTEMS INTERNALS
- NTFS para Windows 98/NTFSDOS Professional
- DebugView v3.21
- Filemon y Regmon v4.21
- Diskmon v1.1
- Systems Internals en www.microsoft.com
- octubre "NT Internals"
- Cosas no tan nuevas
NOTICIAS DE INTERNALS
- Win2K RC2 DDK publicado
- Nuevas API de kernel de Win2K RC
- Desarrollo de software '99 Este
- Uso de DiskEdit
PRÓXIMAMENTE
- Explosión de la API win2K
PATROCINADOR: WINTERNALS SOFTWARE
El Boletín de The Systems Internals está patrocinado por Winternals Software, en la Web en http://www.winternals.com. Winternals Software es el principal desarrollador y proveedor de herramientas avanzadas de sistemas para Windows NT/2K. Los productos de Winternals Software incluyen FAT32 para Windows NT 4.0, ERD Commander (funcionalidad de disco de arranque para Windows NT) y NTRecover.
Remote Recover de Winternals Software le permite acceder a las unidades de un ordenador que no arranca a través de TCP/IP desde cualquier lugar de su empresa. Ahorre tiempo y soporte técnico al corregir remotamente los problemas de controlador, sistema de archivos y configuración que mantienen los sistemas NT o Win9x fuera de línea. Incluso puedes realizar operaciones remotas de chkdsk o de particionado con Remote Recovery, lo que la convierte en una herramienta versátil de recuperación de desastres. Descargue una versión de prueba gratuita de sólo lectura en http://www.sysinternals.com/rrecover.htm, y adquiera la versión de lectura y escritura en http://www.winternals.com.
Hola a todos:
Bienvenido al boletín de Systems Internals. El boletín tiene actualmente 10.000 suscriptores.
El lanzamiento de Windows 2000 (Win2K) parece seguir una pauta de ser inminente y luego retrasarse. Los últimos rumores apuntan a que estará disponible en febrero. Y la única información sobre la fecha de lanzamiento de Win2K son rumores, ya que Microsoft ni siquiera comunica a los fabricantes de equipos originales ni a sus socios cuándo se lanzará. Pues sí: "se enviará cuando esté listo" (no voy a forzar aquí el dicho fechado sobre la venta de vino).
Lo irritante de Microsoft es que la prensa que genera sobre sus productos siempre hace parecer que están a punto de salir al mercado, incluso cuando los productos son vaporware. El ejemplo más reciente es Millennium, el sucesor de Windows 98. Microsoft no hace demasiado tiempo hizo un gran impulso en la prensa como si fuera un producto terminado, listo para convertir todos los dispositivos domésticos en dispositivos inteligentes. Lo irónico es que los artículos publicados poco después revelaron que Microsoft aún no ha definido completamente el producto y que probablemente pasará un año o más antes de que lo veamos en las tiendas.
Este patrón no es nuevo y no soy el primero en escribir sobre él. Pero eso no me impide especular sobre hasta qué punto el vaivén es un plan cuidadosamente orquestado y hasta qué punto es el resultado de una falta total de principios de ingeniería de software. Si se acepta el primer punto de vista, como hacen los teóricos de la conspiración, Microsoft sofoca brillantemente la competencia tentando a los clientes con ese increíble producto que, si esperan sólo un poco más, hará que la espera merezca la pena y obviará cualquier necesidad de recurrir a un producto que no sea de Microsoft. Este último punto de vista expresa que Microsoft nunca aprenderá el proceso de desarrollo de software, y continuamente subestima el esfuerzo de ingeniería y sobreestima la calidad del código beta.
Todavía estoy pensando a qué teoría adscribirme. Creo que el patrón se debe a un poco de ambos. Creo que ha ayudado a Microsoft actuar como si Active Directory estuviera casi listo desde hace dos años. Seguro que hay clientes que habrían recurrido a Novell Directory Services hace mucho tiempo si hubieran sabido de antemano cuánto tendrían que esperar para Win2K. Por otro lado, Microsoft se ha ganado repetidas críticas en la prensa por prometer la entrega de productos y luego retrasarla. Creo que la dirección de Microsoft no entiende lo difícil que es reproducir, aislar y corregir ese último 5% de errores.
Hablando de las prácticas de desarrollo de Microsoft, su esquema de nombres previo al lanzamiento es uno de los más desconcertantes que he visto. Sus betas son realmente alfas y sus candidatos de lanzamiento son en realidad betas. E incluso utilizar estas definiciones es exagerado: Microsoft no tiene ningún problema en eliminar características de su software al pasar de una versión candidata a la siguiente, o incluso en añadir otras nuevas. Lo hicieron con NT 4.0 y lo están haciendo con Win2K. Sin duda, esa práctica no acelera un ciclo de lanzamiento.
¿Así que Win2K saldrá en febrero? Creo que estamos viendo la luz al final del túnel. Después de todo, solo hay un puñado de nuevas API en RC2…
Como continuación del último boletín en el que hablé de la confusión de acrónimos en Microsoft, el lector George Janczuk encontró otro ejemplo. En la sección titulada "Ampliación al mundo del procesamiento de transacciones del mainframe", el artículo en http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm hace referencia a CISC (Complex Instruction Set Computing). Es obvio para cualquiera que esté familiarizado con las aplicaciones de mainframe que el acrónimo previsto es CICS - Customer Information Control System (Sistema de Control de Información al Cliente). Una secuencia de letras invertida y estarás en un área tecnológica totalmente distinta.
Como de costumbre, le rogamos que haga llegar el boletín a los amigos que considere interesantes.
Gracias
-Mark
NOVEDADES DE SYSTEMS INTERNALS
NTFS PARA WINDOWS 98/NTFSDOS PROFESSIONAL
Finalmente lo hemos hecho. Desde que Bryce y yo lanzamos NTFSDOS 1.0 en la primavera de 1996 hemos estado buscando el santo grial de la compatibilidad con los sistemas de archivos de Windows: acceso de lectura/escritura para NTFS desde Windows 9x y DOS. Hace tiempo que nos dimos cuenta de que la ingeniería inversa del formato NTFS y la creación de un controlador para este complejo sistema de archivos con registro diario sería una tarea difícil y arriesgada. Incluso si se determina con precisión cada matiz del formato, una actualización del mismo, como NTFS v5.0 de Win2K, requiere un esfuerzo de ingeniería inversa y desarrollo totalmente nuevo. Además, validar la corrección de un controlador de sistema de archivos para un formato tan intrincado como NTFS es una tarea de enormes proporciones.
Así que hicimos trampa.
NTFS para Windows 98 proporciona acceso completo de lectura/escritura a unidades NTFS desde Windows 95 o Windows 98, y NTFSDOS Professional proporciona acceso completo de lectura/escritura NTFS desde DOS. Ni NTFS para Windows 98 ni NTFSDOS Professional conocen el formato del sistema de archivos NTFS. En su lugar, dependen del controlador NTFS de una instalación de Windows NT o Windows 2000 para implementar ese conocimiento. Ambas utilidades utilizan la misma base de código que sirve como envoltorio de entorno para el controlador del sistema de archivos NTFS. NTFS para Windows 98 proporciona una interfaz con la API del sistema de archivos de Windows 9x por encima de NTFS, y los servicios de disco de Windows 9x por debajo de NTFS. La interfaz que NTFS para Windows 98 presenta a NTFS se parece al entorno nativo de NTFS en Windows NT/2K, completo con IRPs, el I/O Manager, el Cache Manager, dispositivos de disco al estilo NT, y otros subsistemas NT/2K con los que NTFS interactúa.
NTFSDOS Professional funciona de la misma manera que NTFS para Windows 98, excepto que interconecta NTFS con los servicios DOS por arriba y con los servicios de disco BIOS Interrupt 13 por abajo. Para crear un entorno similar al de NT/2K, utilizamos muchas funciones de NTOSKRNL, el archivo del núcleo de NT/2K. Ambas utilidades cargan NTOSKRNL junto con NTFS, para que NTFS pueda utilizar directamente algunos de los servicios nativos del kernel.
Nos divertimos tanto creando el entorno NTFS que fuimos un paso más allá: hicimos lo mismo con la utilidad chkdsk de arranque de NT, Autochk. NTFSDOS Professional y NTFS para Windows 98 vienen con una utilidad NTFS chkdsk llamada NTFSCHK. NTFSCHK funciona según el mismo principio que el envoltorio del sistema de archivos NTFS, en el que crea un entorno similar a NT para el programa Autochk, de modo que Autochk se ejecuta en Windows 95/98 y DOS. El resultado de este truco es un soporte completo de lectura/escritura NTFS para Windows 95/98 y para DOS.
Puedes descargar una versión gratuita de solo lectura de NTFS para Windows 98 en http://www.sysinternals.com/ntfs98.htm y una versión gratuita de solo lectura de NTFSDOS Professional en http://www.sysinternalscom/ntfspro.htm. Puede comprar las versiones completas de lectura y escritura de ambas herramientas en Winternals Software, http://www.winternals.com.
DEBUGVIEW V3.21
DebugView es un monitor de depuración-salida que captura la salida de depuración de Kernel y Win32 en Windows 95, Windows 98, NT 4.0 y Windows 2000. Tiene funcionalidades avanzadas de filtrado, resaltado y registro, e incluso puede capturar la salida de depuración de un sistema a través de una red. Su versión más reciente, 3.21, presenta la capacidad de supervisar la salida OutputDebugString de 16 bits en Windows 95 y Windows 98.
Puede descargar DebugView v3.21 en http://www.sysinternals.com/dbgview.htm.
FILEMON Y REGMON V4.21
Filemon y Regmon son utilidades de sistema de archivos y registro espía para Windows 95, 98, NT 4.0 y Win2K. Siguen evolucionando con nuevas características de facilidad de uso y con la versión 4.21 (Filemon y Regmon tienen números de versión sincronizados) introducen un filtrado más avanzado con listas de filtros recientes, la capacidad de definir un filtro de resaltado (con colores personalizados incluso), fuente personalizable, compatibilidad con portapapeles y más teclas de acceso rápido compatibles con CUI. El código fuente del controlador también se ha revisado e incluye una validación de parámetros más robusta en las funciones de la interfaz gráfica de usuario.
Descargue Filemon v4.21 en http://www.sysinternals.com/filemon.htm y Regmon v4.21 en http://www.sysinternals.com/regmon.htm.
DISKMON V1.1
Diskmon es una herramienta que monitoriza y muestra la actividad lógica y física de los discos. La versión 1.1 actualiza Diskmon para que funcione con Windows 2000 e introduce nuevas mejoras de usabilidad. Además, Diskmon ahora interpreta un gran número de códigos de control de E/S de almacenamiento masivo y de disco, traduciendo sus códigos hexadecimales en representaciones de texto en la ventana de salida de Diskmon.
Diskmon v1.1 no sólo funciona como un monitor de disco, sino que también puede utilizarlo como una luz de disco basada en software. Cuando se configura en el modo de luz de disco, Diskmon se minimiza en la bandeja del sistema como una luz verde cuando hay acceso de lectura al disco y roja cuando hay acceso de escritura al disco.
Descargue Diskmon v1.1 en http://www.sysinternals.com/diskmon.htm.
SISTEMAS INTERNOS EN WWW.MICROSOFT.COM
Teniendo en cuenta la historia de Systems Internals (antes NT Internals), es un gran halago que Microsoft haga referencia a sysinternals.com como recurso para sus clientes. Hay un número creciente de artículos de Microsoft Knowledge Base que apuntan a las utilidades internas de sistemas. Estas son las últimas:
Q183060 INFO: Guía de solución de problemas para 80004005 y otros mensajes de error http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Este artículo describe cómo utilizar Filemon para comprobar la causa de los errores de acceso a datos en OLE DB, Objetos de datos ActiveX y Remote Data Service.Q196453 - Solución de errores de arranque de NTVDM y WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Este artículo también señala a Filemon como una herramienta para determinar qué archivos faltantes están causando errores de inicio para NTVDM (el entorno de compatibilidad Win16/DOS en NT).Q216368 - PRB: Violación de acceso durante la configuración de la aplicación cuando el archivo está en uso http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx y DLLView son herramientas recomendadas para determinar la causa de los errores durante la ejecución de los programas de instalación generados por el Asistente para instalación de Visual Basic y el Asistente de implementación.Q232830 - HOWTO: Determinar la titularidad de los archivos http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx obtiene de nuevo la referencia de este artículo que describe qué proceso tiene abierto un archivo o directorio.
OCTUBRE "NT INTERNALS"
Mi columna "NT Internals" en el número de octubre de Windows NT Magazine es "Inside Win2K Reliability Enhancements, Part 3". Esta tercera parte de una serie de tres describe dos potentes funciones de Win2K que ayudan a desarrolladores y administradores a localizar controladores defectuosos: la memoria del núcleo protegida contra escritura y el verificador de controladores.
Los lectores rusos ya pueden leer mis artículos en su lengua materna. Visite la edición rusa de Windows NT Magazine en http://www.osp.ru/win2000/ y consulte la primera columna traducida de NT Internals, Dentro del proceso de arranque (http://www.osp.ru/win2000/1999/10/59.htm). Gracias a Ivan Rouzanov por informarme de esto.
A partir de agosto, las versiones en línea de los artículos de Windows NT Magazine solo son accesibles para los suscriptores y los artículos se publican en línea con cada nuevo problema. Si aún no se ha suscrito, vaya al enlace de suscripción en http://www.sysinternals.com/publ.htm para obtener el descuento de suscripción a Systems Internals.
COSAS NO TAN NUEVAS
WinObj es una potente herramienta para explorar el espacio de nombres de objetos de Windows NT/2K. El espacio de nombres Object es uno de los tres espacios de nombres de NT/2K: el espacio de nombres Object, el espacio de nombres Registry y el espacio de nombres filesystem. Se accede a los espacios de nombres Registro y Sistema de archivos a través de objetos en el espacio de nombres Objeto. Por ejemplo, cuando un programa Win32 abre la clave del Registro HKEY_LOCAL_MACHINE\Software\Microsoft, la biblioteca ADVAPI32.DLL transforma el nombre en \Registry\Machine\Software\Microsoft antes de llamar al servicio del núcleo NtCreateKey. Si observa la raíz del espacio de nombres Object en WinObj, verá un objeto de tipo "key" denominado Registry. El nombre del Registro coincide con el primer componente del nombre de clave, por lo que el Administrador de objetos NT/2K pasa el resto del nombre, \Machine\Software\Microsoft, al subsistema que define el objeto de clave. El subsistema de kernel Configuration Manager mantiene el Registro y los objetos de clave, por lo que analiza el resto del nombre para buscar la clave deseada.
Puede explorar el espacio de nombres Object y ver o establecer propiedades de seguridad de objetos mediante WinObj. Descargar WinObj en http://www.sysinternals.com/winobj.htm. Hablo del espacio de nombres del Gestor de Objetos y de WinObj en mi columna de octubre de 1997 sobre NT Internals, "Dentro de la gestión de objetos". Abre un enlace que lleve a la versión en línea de la columna en http://www.sysinternals.com/publ.htm.
NOTICIAS DE INTERNALS
WIN2K RC2 DDK PUBLICADO
Ya puede descargar la versión Win2K RC2 del kit de desarrollo de controladores de dispositivos (DDK) de Microsoft en http://www.microsoft.com/ddk/ddkRC2.htm. Puede descargar el kit de forma gratuita o examinar la documentación en línea.
NUEVAS API DE KERNEL DE WIN2K RC2
Las cosas parecen estar estabilizando en el kernel win2K más reciente. Sólo hay cuatro nuevas API del núcleo exportadas en RC3, frente a la docena que aparecieron (y otra media docena que desaparecieron) al pasar de Beta 3 a RC1. Varias de las nuevas funciones son algo interesantes, así que he decidido documentarlas para usted. El primero es MmGetSystemRoutineAddress, y aunque no está documentado, su prototipo se incluye en el archivo de encabezado ntddk.h del RC2 DDK:
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Su uso es tan sencillo como parece. Introduzca el nombre de una función que resida en NTOSKRNL.EXE o HAL.DLL y obtendrá la dirección de su punto de entrada. Esta función es realmente inútil en la primera versión de Win2K, pero puede llegar a ser muy útil más adelante, y es una función que Microsoft debería haber incluido en la primera versión de NT (3.1). Al igual que GetProcAddress en el espacio de usuario para aplicaciones Win32, esta función permite a un controlador determinar dinámicamente la disponibilidad de una API. Si Microsoft añade nuevas API a los paquetes de servicio de Win2K (y estoy seguro de que lo hará), los controladores pueden escribirse para aprovechar las API, pero también para fallar con elegancia en versiones anteriores de Win2K o para ejecutarse en un modo en el que no utilicen las API. La clave para que un controlador pueda hacer esto es la capacidad de comprobar la presencia de las API tras la carga. Sin esta funcionalidad, un controlador tiene que enlazar estáticamente con las funciones que utiliza, y si las funciones no están presentes cuando se carga el controlador, el cargador del kernel informa al usuario de un desagradable error y no carga el controlador.
La segunda NUEVA API es MmGetPhysicalMemoryPages. De nuevo, su prototipo está en el RC2 ntddk.h, pero no está documentado. Su prototipo es:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Donde PHYSICAL_MEMORY_RANGE es:
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Esta función devuelve una matriz de PHYSICAL_MEMORY_RANGE entradas con el final de la matriz marcada por una entrada que tiene 0 para BaseAddress y NumberOfBytes. Como MmGetSystemRoutineAddress, es una API bastante sencilla. Devuelve una descripción de toda la memoria física que Win2K conoce. Win2K admite la adición y eliminación de memoria sobre la marcha con las MmAddPhysicalMemory API y MmRemovePhysicalMemory. Esto motiva la razón de la existencia de una API que le permite consultar intervalos de memoria. MmAddPhysicalMemory se agregó en RC1 y MmRemovePhysicalMemory en RC2. Ambas funciones también se crean prototipos en ntddk.h.
¿Cuáles son las otras NUEVAS API rc2? PoShutdownBugCheck y RtlInvertRangeList. PoShutdownBugCheck permite bloquear el sistema y realizar una acción relacionada con la energía, como suspender. Se usa en un par de lugares por el kernel RC2. Los intervalos son especificaciones genéricas de inicio y finalización que son definidas por el usuario y compatibles con una serie de API de kernel para administrar, ordenar e iterar sobre ellos. Los árbitros de recursos Plug-and-Play de Win2K los utilizan para rastrear y organizar los requisitos de recursos de hardware. Aunque las API de listas de rangos no están documentadas, todos sus prototipos y definiciones de estructura están incluidos en ntddk.h, por lo que es de suponer que podrías utilizar la API para gestionar tus propios datos orientados a inicio-fin.
Esté atento a los próximos boletines para saber más sobre las API no documentadas.
DESARROLLO DE SOFTWARE 99 ESTE
La edición de 1999 de la Costa Este de Desarrollo de Software tendrá lugar en Washington D.C. del 8 al 12 de noviembre. El último día presentaré tres charlas: Novedades de Windows 2000 para desarrolladores, Dentro de la pantalla azul de Windows NT/2000 y Dentro de las redes de Windows NT/2000. Además, Dave Salomón, autor de Dentro de la 2a edición de Windows NT, y un vecino (vive a tan solo 20 minutos de mí en, de todos los lugares, Danbury, CT) y yo hospedamos una mesa redonda interna de Windows NT/2K. Estaremos juntos para responder a sus preguntas más difíciles sobre el funcionamiento interno de Windows NT/2K. Saluda y menciona el boletín y te regalaré una camiseta de Systems Internals.
Visita el sitio web de desarrollo de software en http://www.sdexpo.com.
USO DE DISKEDIT
Es posible que no lo sepas, pero hay una utilidad de editor de discos para Windows NT en el estilo de la venerada Norton Disk Edit para DOS. Además, la utilidad entiende FAT y NTFS y es gratis. Aparentemente, Microsoft envió DiskEdit accidentalmente, una herramienta que debe ser una herramienta de depuración interna para sus equipos de sistemas de archivos, en el CD de Windows NT 4.0 Service Pack 4. DiskEdit tiene una interfaz peculiar que requeriría un pequeño manual para documentar, pero voy a empezar con un simple tutorial. Me centraré en el uso de DiskEdit para desentrañar el formato del sistema de archivos NTFS, ya que DiskEdit es la única herramienta disponible públicamente que conozco que entiende NTFS.
En primer lugar, debe obtener DiskEdit desde el CD-ROM de Service Pack 4 (SP4). Simplemente cópielo del directorio \i386 en el disco duro. Si quieres usar DiskEdit en Win2K, tendrás que crear un directorio privado para él y copiar los siguientes archivos DLL de un directorio SP4 winnt\system32 (o SP4 CD) en el mismo directorio que DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL y UFAT.DLL. Ahora puede iniciar DiskEdit.
Para este tutorial, cree un directorio llamado TEMP en la raíz de una unidad NTFS y cree un archivo llamado OUT.TXT en ese directorio escribiendo el siguiente comando en una ventana de símbolo del sistema con TEMP como directorio actual: echo hello > out.txt. Seleccione la unidad con su nuevo archivo OUT.TXT en DiskEdit eligiendo la opción de menú File|Open e introduciendo la letra de la unidad en el campo Volume Name del cuadro de diálogo resultante. Asegúrese de incluir los dos puntos, por ejemplo, "d:". Prácticamente todas las funciones de DiskEdit requieren que haya abierto una unidad.
Vamos a buscar el archivo OUT.TXT iniciando en el directorio raíz de la unidad NTFS. Seleccione la entrada de menú Leer|Registro de archivo NTFS para abrir un cuadro de diálogo que le permite ver cualquier entrada de registro MFT con sólo introducir su número. Las 16 primeras entradas del registro MFT de cada unidad NTFS están reservadas y corresponden a archivos de metadatos NTFS predefinidos. Aquí están las asignaciones de números (tenga en cuenta que DiskEdit interpreta toda la entrada como hexadecimal):
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)
Eche un vistazo a algunas de estas entradas MFT. Empezará a observar un tema común: todos constan de atributos como $INDEX_ROOT, $FILE_NAME y $DATA. Es en los atributos donde se almacenan los datos específicos de un archivo. Cuando los datos de atributos son pequeños NTFS almacena los datos dentro del registro MFT del archivo como datos "residentes", y cuando los datos son grandes NTFS almacena los datos externos al registro en clusters en el disco como datos "no residentes".
Ahora escriba "5" como número de archivo y verá el archivo del directorio raíz. Vamos a ver los archivos y directorios que se encuentran en el directorio raíz visualizando el atributo $INDEX_ALLOCATION del directorio, un atributo específico de los directorios que registra el contenido de un directorio. Para ello, seleccione la entrada de menú Leer|Atributo NTFS, que abre otro cuadro de diálogo. DiskEdit es sensible a mayúsculas y minúsculas, así que introduzca lo siguiente exactamente como lo he indicado:
Base Frs Number: 5
Base Frs (Base File Record Segment) es otro nombre para el número MFT. Escriba en 5 para especificar que desea leer un atributo desde el directorio raíz.
Attribute Type: $INDEX_ALLOCATION
Esto indica a DiskEdit que desea leer los datos de contenido del directorio. Le recomiendo que utilice el menú desplegable para elegir el atributo que desee, ya que DiskEdit es muy quisquilloso con la forma en que se introduce el tipo de atributo.
Attribute Name: $I30
Si ves el atributo $INDEX_ALLOCATION del directorio raíz verás que "$I30" aparece como su nombre en su línea "Type code, name", así que eso es lo que introduces como nombre del atributo.
Presione Aceptar y verá un volcado hexadecimal del contenido del atributo. Queremos ver algo más inteligible, así que seleccione la entrada de menú View|NTFS Index Buffer. Aparecerá la lista del contenido del directorio. Desplácese por el listado hasta que vea la entrada que tiene el nombre "TEMP". Si no lo ve, es posible que la entrada se encuentre en el atributo del directorio raíz $INDEX_ROOT, un tipo de atributo también asociado a los directorios y que siempre tiene su valor almacenado en el registro MFT. Las entradas raíz del índice y las entradas de asignación forman una estructura de árbol B+ que almacena todas las entradas de un directorio. Si tienes que ver el atributo $INDEX_ROOT sólo tienes que seguir los mismos pasos para ver ese atributo que para ver el atributo $INDEX_ALLOCATION. Al desplazarte por una memoria intermedia de índice, puedes encontrarte con dos líneas de asteriscos: éstas indican el final de una memoria intermedia de índice y el principio de la siguiente.
Una vez que haya encontrado la entrada del directorio TEMP, anote su referencia de archivo (FRS). Seleccione Read|NTFS File Record e introduzca el FRS de TEMP. Ahora estás viendo el registro MFT para el directorio TEMP. Queremos encontrar el archivo OUT.TXT, así que tendremos que buscar en el contenido de TEMP para encontrarlo. Visualice el atributo $INDEX_ALLOCATION (o $INDEX_ROOT) del directorio TEMP, cambie a la visualización de los datos como un búfer de índice NTFS y localice el archivo OUT.TXT. No olvide escribir FRS de TEMP como número de FRS base en el cuadro de diálogo de selección de atributos. Si acaba de crear TEMP entonces sólo tendrá un $INDEX_ROOT (si teclea mal algo tendrá el placer de ver uno de los diálogos de error vacíos de DiskEdit).
Cuando haya encontrado OUT.TXT y determinado su FRS utilice Read|NTFS File Record para mirar su entrada MFT. Desplácese hacia abajo hasta encontrar el atributo $DATA. Ahora está viendo la ubicación de los datos de OUT.TXT. Dado que hemos realizado un archivo pequeño, los datos se almacenan en el registro MFT. Si intenta ver el atributo $DATA de OUT.TXT utilizando DiskEdit no verá nada, ya que DiskEdit no muestra correctamente los datos residentes (uno de los muchos errores de DiskEdit). Así pues, copie un archivo de texto de gran tamaño (> 2 KB) en \TEMP\ OUT.TXT. Ahora puede ver los datos de OUT.TXT de una de estas dos maneras: puede examinar el inicio de los datos (o todos ellos si se almacenan contiguamente en el disco) mediante Read|Clúster NTFS y especificación del primer valor "lcn" que se ve en el atributo de OUT.TXT $DATA "Lista de extensiones"; o puede usar Read|Atributo NTFS y escriba "$DATA" como tipo de atributo y nada (como en no escriba nada en ese campo) como nombre del atributo.
Las listas de extensiones describen la ubicación de los datos no residentes de un atributo. Cada bloque contiguo de datos de hasta 16 clústeres de longitud se describe mediante una entrada de lista de extensiones. Una entrada de lista de extensiones especifica un número de clúster virtual (vcn), un número de clúster lógico (lcn) y una longitud de ejecución. Un vcn es el clúster dentro del archivo en el que se inician los datos descritos por la entrada. Un Lcn designa el cluster lógico donde se almacenan los datos en el disco, y el runlength es el número de bytes de datos de atributos en esa ubicación (recuerde, DiskEdit le está mostrando valores hexadecimales).
He recorrido el camino largo para encontrar el registro MFT del archivo OUT.TXT mostrándole cómo escanear el contenido del directorio. Sin embargo, hay un atajo: seleccione Crack|NTFS Path e introduzca TEMP\OUT.TXT. Se te presentará el FRS de OUT.TXT y puedes usar Read|NTFS File Record para ir directamente a él.
Eso me lleva al final de la primera versión de DiskEdit. Te animo a jugar con esta herramienta ingeniosa explorando tus unidades FAT o NTFS. Es muy poco probable que alguna vez tenga que utilizar DiskEdit para modificar datos con el fin de sacar su disco de un atasco, pero si tiene curiosidad sobre el formato NTFS en disco (el formato FAT está bien documentado) esta es la herramienta perfecta para investigar.
PRÓXIMAMENTE
EXPLOSIÓN DE LA API DE WIN2K
Aunque sólo hay 4 nuevas API exportadas en modo kernel que debutaron en RC2, el número total de API que Microsoft ha introducido desde NT 4.0, tanto en el kernel como en las DLL Win32 principales, se ha disparado. El mes que viene les contaré exactamente cuántas API nuevas hay y dónde han aparecido, y desgraciadamente, al mismo tiempo daré a la gente que cree que Win2K es un monstruo hinchado una gran cantidad de material para sus diatribas en alt.advocacy.linux Usenet.
Gracias por leer el Boletín de Systems Internals.
Publicado el miércoles 20 de octubre de 1999 7:10 p. m. por ottoh
[Archivo de boletines ^] [< Volumen 1, Número 4] [Volumen 2, Número 1 >]