2011-06-13 9 views
11

Desde MSDN documentation para la propiedad FileInfo.Name, veo que los datos de la propiedad se almacenan en caché la primera vez que se llama y solo se actualizarán posteriormente mediante el método Refresh.Caché de propiedades de FileInfo en C#

He las siguientes preguntas que no puedo encontrar o no está demasiado claro en la documentación:

  1. son los datos para todas las propiedades en caché al mismo tiempo?

  2. ¿Se requiere el método Refresh para la creación del FileInfo, o solo cuando se llama a una propiedad por primera vez?

  3. Si he llamado a una propiedad, p. la propiedad Name, y se llama Refresh, llamará a una propiedad diferente, p. la propiedad DirectoryName, por primera vez, hace que vuelva a llamar al Refresh, o solo la llama la primera propiedad a la que se accede en toda la clase (consulte la pregunta # 1)?

  4. ¿Puedo precachear todas las propiedades llamando al Refresh manualmente? (Suponiendo que no está preguardado en la caché en la construcción del objeto)

  5. ¿Las propiedades de llamada Refresh causan manualmente que son pre-cached, p. CreationTime, para actualizarse también?

+2

Yo sugeriría que descargue ILSpy http://wiki.sharpdevelop.net/ILSpy.ashx y examinar la implementación de FileInfo. Es la mejor manera de obtener respuestas a preguntas tan detalladas sobre los aspectos internos de los tipos de BCL. – bentayloruk

+0

Estoy de acuerdo. También vale la pena señalar que ahora (bueno, como en el día de hoy) puede navegar por la fuente de referencia en línea. Aquí está la [definición de FileInfo] (http://referencesource.microsoft.com/#mscorlib/system/io/fileinfo.cs,4ee673c1a4ecad41) en todo su esplendor. –

Respuesta

4
  1. En una conjetura, sí. Parece una "optimización" contraproducente para FileInfo obtener solo las propiedades que ha buscado antes, especialmente cuando pueden (y probablemente lo son) todas buscarse en one API call.

  2. El hecho de que la documentación llama DirectoryInfo métodos que sirven hasta que ya en caché-FileInfo s sugiere con mucha fuerza (al menos para mí) que simplemente construir un FileInfo no almacena en caché nada. Tiene sentido: si construyes un FileInfo directamente, podría referirse a un archivo que aún no existe (planeas crearlo, por ejemplo), mientras que todos los métodos que devuelven el FileInfo guardados en caché se refieren a los archivos que existen en el momento de la instantánea, bajo el supuesto de que va a usar al menos algunos de ellos.

  3. No, por mi respuesta a la pregunta 1. Es por eso que el método Refresh está ahí.

  4. Me lo imagino (ver respuesta 1).

  5. Sí. Ver respuesta 3.

2

El valor de la propiedad CreationTime está pre-almacenado en caché si la corriente instancia del objeto FileSystemInfo fue devuelto desde cualquiera de los siguientes métodos DirectoryInfo:

  • GetDirectories
  • GetFiles
  • GetFileSystemInfos
  • EnumerateDirectories
  • EnumerateFiles
  • EnumerateFileSystemInfos

Para obtener el valor más reciente, llame al método Refresh.

Si no existe el archivo se describe en el objeto FileSystemInfo, esta propiedad devolverá 12:00 de la noche, 1 de enero 1601 dC (C. E.) Tiempo Universal Coordinado (UTC), ajustado a la hora local.

Las unidades con formato NTFS pueden almacenar en memoria caché meta-información del archivo, como la creación de archivos de tiempo, durante un período corto de tiempo. Este proceso se conoce como archivo tunelización. Como resultado, puede ser necesario establecer explícitamente el tiempo de creación de un archivo si está sobrescribiendo o reemplazando un archivo existente .

(MSDN)

Internamente Refresh, pide el estándar Win32API y por lo tanto llena todas las propiedades.

[...] 
flag2 = Win32Native.GetFileAttributesEx(path, 0, ref data); 

Acceso a cualquier propiedad que se especifica para actualizar provoca una actualización completa, por ejemplo:

public DateTime LastAccessTimeUtc 
{ 
    [SecuritySafeCritical] 
    get 
    { 
     if (this._dataInitialised == -1) 
     { 
      this._data = default(Win32Native.WIN32_FILE_ATTRIBUTE_DATA); 
      this.Refresh(); 
     } 
     [...] 
Cuestiones relacionadas