¿Cómo asegurar que todos los datos se han escrito físicamente en el disco?

StackOverflow https://stackoverflow.com/questions/383324

  •  23-08-2019
  •  | 
  •  

Pregunta

Yo entiendo que método Flush de .NET FileStream sólo escribe el búfer en el disco, pero dependiente de controlador de disco de Windows y el firmware del disco duro esto no es garantía de que los datos se escribe realmente físicamente en el disco.

¿Hay un método .NET o Win32 que me puede dar esta garantía? Así que si se produce una pérdida de potencia de un nanosegundo después de la llamada a este método regresa, aún puedo estar seguro de que todo está bien?

¿Fue útil?

Solución

En Windows, observe FlushFileBuffers (Win32 API).

Otros consejos

Stefan S. dijo:

  

Yo entiendo que método Flush de .NET FileStream sólo escribe el búfer en el disco

No, al ras de .NET FileStream sólo escribe las memorias intermedias de .NET a la caché del sistema operativo, no vaciar el caché del sistema operativo en el disco. Por desgracia, el doc MSDN en esta clase no dice eso. Para .NET <4,0, se le tiene que llamar FlushFileBuffers Enjuague + Win32 de: 

using System.Runtime.InteropServices;
. . .

// start of class:
[DllImport("kernel32", SetLastError=true)]
private static extern bool FlushFileBuffers(IntPtr handle);
. . .

stream.Flush();     // Flush .NET buffers to OS file cache.
#pragma warning disable 618,612 // disable stream.Handle deprecation warning.
if (!FlushFileBuffers(stream.Handle))   // Flush OS file cache to disk.
#pragma warning restore 618,612
{
  Int32 err = Marshal.GetLastWin32Error();
  throw new Win32Exception(err, "Win32 FlushFileBuffers returned error for " + stream.Name);
}

Para .NET 4.0, en su lugar puede utilizar el nuevo método (verdadero) a ras. 11/09/2012 actualización: MS informe de error aquí dice que se ha roto, a continuación, fija, pero no dice qué versión o Service Pack que se fijó en! Suena como si fue error buffer interno .NET FileStream está vacía, la Escalera (verdadero) no hizo nada ??

Bueno, se podría cerrar el archivo ... que probablemente lo haría. En realidad, con la abstracción de HAL, la virtualización y el hardware del disco ahora con más potencia de procesamiento y memoria caché de ordenadores hice hace unos años, vas a tener que vivir con la esperanza de que el disco hace su trabajo .

El sistema de archivos transaccional en realidad nunca se materializó ;-P Por supuesto, que tal vez podría contemplar la utilización de una base de datos como parte de atrás, y utilizar el sistema de transacción de eso?

Aparte: tenga en cuenta que no todas las corrientes incluso garantizan a Flush() - por ejemplo, GZipStream etc conservar una memoria intermedia de trabajo de datos no confirmados, incluso después de un lavado - la única manera de llegar a cisterna todo es Close() él.

Me he dado cuenta de que el .NET 4 #Flush (verdadero) en realidad no escribir en el disco. Estábamos teniendo problemas extraños con datos dañados y yo encontramos este informe de error en el sitio EM:

La pestaña de detalles de informe de fallos tiene un programa de prueba se puede ejecutar que mostrará el tema;

  1. Escribir un montón de datos en el disco
  2. fs.Flush(true). Esto toma tiempo (mucho más rápido que posiblemente se escriben en el disco).
  3. Utilice el FlushFileBuffers API Win32. Esto toma mucho tiempo.

Estoy cambiando a los FlushFileBuffers Win32 llamar ...

Los datos del archivo que se almacenar en el caché del sistema de archivos que se escriben en el disco. Esos datos son normalmente perezosamente escrito, en base a la posición de la cabeza de escritura en disco. Tener un gigabyte de datos en caché es técnicamente posible para que pueda tomar un buen tiempo. Si esto es importante para ti, entonces considerar la opción FileOptions.WriteThrough lugar.

  

Hay una respuesta simple a vaciar el contenido de la memoria intermedia en el disco.   Después de que su función WriteAllText, archivo abierto, cerrarlo y reiniciarlo

     

Este es un ejemplo 

My.Computer.FileSystem.WriteAllText(yourfilename, "hello", False, System.Text.Encoding.ASCII)
FileOpen(1, yourfilename, OpenMode.Input)
FileClose(1)
Reset()

Simplemente hay demasiados niveles de abstracción para estar absolutamente seguro de que los datos se escriben en el disco, hasta el nivel de hardware.

No brillantemente performant o infalible, pero ¿qué hay de volver a abrir el archivo una vez que se escribe en un proceso separado y comprobar el tamaño o el contenido?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top