Confidencial de WindowsEl poder de los errores

Raymond Chen

En Windows 95 , se podía ir a la página de solución de problemas y seleccionar la opción para deshabilitar las confirmaciones de búferes sincrónicas. Pero, ¿sabe usted lo que hacía esta casilla de verificación? ¿O por qué?

El comportamiento normal de la función Commit de MS-DOS® consistía en vaciar todos los datos no escritos de un archivo concreto al disco, y esperar a que los datos se hubieran confirmado como escritos antes de volver. Si estaba activada la opción para deshabilitar las confirmaciones de búferes sincrónicas, la llamada se devolvía inmediatamente, en lugar de esperar a que se escribieran los datos. Esto, por supuesto, era una infracción de la especificación de la función, que requiere que la llamada no se devuelva hasta que se han escrito los datos. Así se aumentaba el riesgo de lo que en el artículo 139669 de Knowledge Base se denomina eufemísticamente "problemas de integridad de archivo", ya que hacía que el programa que emitía la solicitud de vaciado pensara que los datos estaban seguros en el disco, cuando en realidad no lo estaban.

Un programa de base de datos puede usar la función Commit para establecer puntos en que el estado del archivo del disco es el que el programa espera que sea. Si se produce una interrupción de suministro eléctrico en el equipo durante una actualización, el programa de base de datos puede usar la información registrada en el último punto de confirmación para restablecer la integridad de la base de datos. Si la función Commit se devolvía inmediatamente antes de que se terminara la confirmación, se perdía este punto de control de integridad. El resultado era que la base de datos quedaba dañada.

¿Por qué estaba disponible esta opción disponible si las consecuencias eran tan negativas? La causa: un error de Windows® 3.11.

Figura 1** Habilitar el comportamiento con errores en Windows Server 2003 **(Hacer clic en la imagen para ampliarla)

En Windows 3.11 apareció el “acceso a archivos de 32 bits", una implementación de 32 bits de la interfaz de E/S de archivos de nivel inferior. Pero la implementación de la función Commit tenía un error que omitía eficazmente las solicitudes para vaciar los búferes de archivos. Si se ejecutaba en Windows 3.11 un programa que vaciaba sus búferes de archivos, la llamada al vaciado no tenía efecto. En consecuencia, si se perdía el suministro de energía justo en el momento menos indicado, la base de datos quedaba dañada.

Los desarrolladores que trabajaron en el sistema de archivos de Windows 95 corrigieron este error, pero empezaron a llegar otros informes de errores. El programa de contabilidad de un usuario empezó a funcionar muy despacio. Después, el programa de base de datos de otro usuario hizo lo mismo. ¿Qué estaba pasando?

Resultó que estos programas emitían constantes llamadas de vaciado. Los programadores advirtieron que las llamadas de vaciado eran muy rápidas en Windows 3.11, así que las agregaron por todas partes en su programa. Escribir un byte, vaciar. Escribir una cadena, vaciar. Como los vaciados eran tan rápidos, la aplicación podía confirmar los datos en el disco después de cada operación, sin que el rendimiento se viera afectado. Pero una vez que en Windows 95 se corrigió el error, estos programas empezaron a tener un rendimiento muy lento, porque las llamadas a la función Commit, de repente, hacían trabajo real.

Por supuesto, si el equipo del sistema de archivos no hubiera hecho nada, estos programas hubieran seguido siendo muy lentos y los usuarios habrían llegado a la conclusión de que el problema era Windows 95. "Windows 95 es lentísimo", se decían unos a otros. Por otro lado, si el sistema de archivos volvía a tener el comportamiento de Windows 3.11, habrían vuelto a introducir un error que podría conducir a esos molestos "problemas de integridad de los archivos".

Concluyeron que la solución era dejar la corrección del error y agregar una casilla de verificación (casi oculta en la página de solución de problemas) para volver al comportamiento de Windows 3.11 para los usuarios que ejecutaban programas y se encontraban los problemas derivados de dicha corrección.

Más adelante, la historia se volvió a repetir. En Windows Server® 2003, el equipo de E/S descubrió un error en que las solicitudes etiquetadas como Forced Unit Access (FUA) perdían la etiqueta de FUA y se ejecutaban como E/S normal. Era como una nueva manera de omitir las solicitudes de vaciado. Corrigieron el error, pero mantuvieron la opción de volver al comportamiento anterior con el error. La versión de Windows Server 2003 de esta casilla se llama "Habilitar rendimiento avanzado", pero ahora ya sabe que, en realidad, significa "Restaurar el comportamiento anterior con el error".

Raymond ChenThe Old New Thing, y su libro del mismo título (Addison-Wesley, 2007) tratan de la historia de Windows y la programación de Win32. Él respeta la ley al pie de la letra.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.