Cuando redirijo la salida de un comando a un archivo (por ejemplo, echo Hello > file) ¿se garantizará que ese archivo tenga dichos datos justo después de que el comando salga? ¿O todavía hay una ventana muy pequeña entre las salidas de comando y los datos escritos en el archivo? Me gustaría leer el archivo justo después de que salga el comando, pero no quiero leer un archivo vacío.

Hay múltiples capas de memorias intermedias / cachés involucradas.

1. El caché de la CPU.

   Los datos se juntan byte a byte y se almacenan en el caché de la CPU. Si el caché de la CPU está lleno y no se ha accedido a los datos durante un tiempo, el bloque que contiene nuestros datos puede escribirse en la memoria principal. Estos están, en su mayor parte, ocultos para los programadores de aplicaciones.

2. Los amortiguadores en proceso.

   Hay un poco de memoria reservada en el proceso donde se recopilan los datos, por lo que debemos realizar la menor cantidad posible de solicitudes al sistema operativo, ya que es relativamente costoso. El proceso copia los datos en estos búferes, que nuevamente pueden estar respaldados por cachés de la CPU, por lo que no hay garantía de que los datos se copien en la memoria principal. La aplicación necesita vaciar explícitamente estos búferes, por ejemplo, usando fclose (3) o fsync (3). La función exit (3) también hace esto antes de que finalice el proceso, mientras que la función _exit (2) no lo hace , por lo que hay una gran advertencia en la página del manual para que esa función lo llame solo si sabe lo que es haciendo.

3. El kernel amortigua

   Luego, el sistema operativo mantiene su propia caché, para minimizar la cantidad de solicitudes que necesita enviar a los discos. Este caché no pertenece a ningún proceso en particular, por lo que los datos allí pueden pertenecer a procesos que ya han finalizado, y dado que todos los accesos pasan por aquí, el siguiente programa verá los datos si ha llegado aquí. El núcleo escribirá estos datos en los discos cuando tenga tiempo de hacerlo o cuando se le solicite explícitamente.

4. El caché de la unidad

   Las unidades de disco también mantienen un caché para acelerar los accesos. Estos se escriben con bastante rapidez, y hay un comando para escribir los datos restantes en los cachés e informar cuando se completa, que el sistema operativo utiliza en el apagado para asegurarse de que no quedan datos sin escribir antes de apagarse.

Para su aplicación, es suficiente que los datos se registren en las memorias intermedias del kernel (los datos reales todavía pueden vivir en cachés de CPU en este momento, y podrían no haberse escrito en la memoria principal): el proceso "echo" finaliza, lo que significa que cualquier búfer en proceso debe haberse vaciado y los datos entregados al sistema operativo, y cuando inicia un nuevo proceso, se garantiza que el sistema operativo devolverá los mismos datos cuando se le solicite.

Si la aplicación no tiene cachés internos, los cambios se escribirán inmediatamente en el archivo. Lo mismo para tu ejemplo. El archivo es una entidad lógica en la memoria que se actualizará inmediatamente. Cualquier operación posterior en el archivo verá los cambios realizados por el programa.

Sin embargo , esto no significa que el cambio se haya escrito en el disco físico. Los cambios pueden permanecer en las cachés del sistema de archivos del sistema operativo o en las cachés de hardware. Para vaciar los búferes del sistema de archivos, use el synccomando

Me gustaría leer el archivo justo después de que salga el comando, pero no quiero leer un archivo vacío.

No deberías encontrarte con ningún problema práctico aquí.

¿El búfer se vaciará automáticamente al disco cuando salga un proceso?

En general la respuesta es no .

Depende del comando. Como mencionan las otras respuestas, si el comando no almacena internamente los datos, todos los datos estarán disponibles cuando finalice el comando.

Pero la mayoría, si no todas, las bibliotecas de E / S estándar hacen stdout de búfer de forma predeterminada (hasta cierto punto) y ofrecen diferentes garantías sobre el vaciado automático de búferes cuando se cierra la aplicación.

C garantiza que una salida normal vaciará los tampones . "Salida normal" significa que exitse llama, ya sea explícitamente o al regresar de main. Sin embargo, una salida anormal puede eludir esta llamada (y, por lo tanto, dejar atrás los búferes sin vaciar).

Aquí hay un ejemplo simple:

#include <signal.h>
#include <stdio.h>

int main() {
    printf("test");
    raise(SIGABRT);
}

Si compila esto y lo ejecuta, testserá no necesariamente deben escribir en la salida estándar.

Otros lenguajes de programación ofrecen aún menos garantías: Java, por ejemplo, no se auto-descarga al finalizar el programa . Si el búfer de salida contiene una línea sin terminar, puede perderse, a menos que System.out.flush()se llame explícitamente.

Dicho esto, su cuerpo pregunta se refiere a algo ligeramente diferente: si los datos llegan en el archivo en absoluto , debe hacerlo inmediatamente después de la expiración de la orden (sujeta a las advertencias descritas en las otras respuestas).

Creo que ninguna pregunta aborda este problema lo suficiente todavía:

Me gustaría leer el archivo justo después de que salga el comando, pero no quiero leer un archivo vacío.

Como explican las otras respuestas, un programa que se comporta bien vacía sus búferes de archivos internos antes de que el proceso finalice normalmente . Posteriormente, los datos pueden permanecer en el núcleo o en las memorias intermedias de hardware antes de escribirse en el almacenamiento persistente. Sin embargo , la semántica del sistema de archivos de Linux garantiza que todos los procesos vean el contenido de los archivos de la misma manera que lo hace el núcleo, incluidos los buffers internos ¹ .

Esto se implementa típicamente teniendo como máximo un búfer en el núcleo por objeto de archivo y para requerir que todo el acceso a los archivos pase por este búfer.

• Si un proceso lee un archivo, el núcleo presentará el contenido del búfer al proceso, si la parte del archivo solicitado está actualmente en el búfer; si no es así, el núcleo buscará los datos del medio de almacenamiento subyacente y lo colocará dentro del búfer, luego volverá al paso anterior.

• Si un proceso escribe en un archivo, los datos se colocan primero dentro del búfer en el núcleo para ese archivo. Finalmente, el contenido del búfer se vaciará al almacenamiento. Mientras tanto, el acceso de lectura se satisface desde el mismo búfer (ver arriba).

¹ Al menos para archivos regulares, directorios y enlaces simbólicos. FIFOs y sockets son un asunto diferente ya que su contenido nunca se almacena de forma persistente de todos modos. Hay algunos casos especiales de archivos regulares cuyo contenido depende de quién pregunta; ejemplos son archivos en procfs y sysfs (piense /proc/selfque es un enlace simbólico al ID del proceso del proceso que lee el enlace simbólico).

Suponiendo que su comando es ejecutado por algún programa que usa la biblioteca de tiempo de ejecución C, en algún momento debería invocar fclosepara cerrar el archivo abierto.

La página del manual para la fclosefunción C dice:

NOTAS Tenga en cuenta que fclose () solo vacía los búferes de espacio de usuario proporcionados por la biblioteca C. Para garantizar que los datos se almacenen físicamente en el disco, los búferes del núcleo también se deben vaciar, por ejemplo, con sync (2) o fsync (2).

y la página de manual para fflushtiene la misma nota. La página del manual closedice:

Un cierre exitoso no garantiza que los datos se hayan guardado correctamente en el disco, ya que el núcleo difiere las escrituras. No es común que un sistema de archivos vacíe los búferes cuando se cierra la secuencia. Si necesita asegurarse de que los datos están almacenados físicamente, use fsync (2). (Dependerá del hardware del disco en este momento).

Tenga en cuenta que los datos están disponibles para otros procesos, incluso si no están sincronizados con la unidad. Tal vez eso ya sea lo suficientemente bueno para ti.

Si tiene dudas, escriba una prueba.

Cuando redirijo la salida de un comando a un archivo (por ejemplo, echo Hello > file) ¿se garantizará que ese archivo tenga esos datos justo después de que el comando salga?

Sí. El shell abre el archivo de echosalida y lo envía directamente a eso. Una vez que sale el comando, está listo.

¿O todavía hay una ventana muy pequeña entre las salidas de comando y los datos escritos en el archivo?

Si los datos ya están en los medios es otra cuestión, lo que solo importa si después hay una falla de hardware, o si inspecciona la partición en vivo con algún software forense, sin pasar por el sistema de archivos montado.

Me gustaría leer el archivo justo después de que salga el comando, pero no quiero leer un archivo vacío.

No se preocupe, el núcleo solo mantiene una vista del archivo, independientemente de la frecuencia con la que se abre.

Como regla general, cualquier dato que posea el kernel es mantenido y limpiado por el kernel, punto. Dichos datos incluyen datos transferidos a la memoria del kernel por una llamada al sistema como write(2).

Sin embargo, si su aplicación (por ejemplo, la biblioteca C) realiza el almacenamiento en búfer además de esto, entonces el núcleo obviamente no tiene idea y, por lo tanto, no garantiza su limpieza.

Además, no creo que haya ninguna garantía de tiempo para la limpieza; en general, se realiza con el "mejor esfuerzo" (léase: "cuando tengo un segundo").

¿O todavía hay una ventana muy pequeña entre las salidas de comando y los datos escritos en el archivo?

No, no hay

Me gustaría leer el archivo justo después de que salga el comando, pero no quiero leer un archivo vacío.

Puede leer el contenido final del archivo justo después de que salga el comando; en su lugar, nunca leerá el archivo vacío. (En C y C ++, use las llamadas al sistema wait , waitpid , wait3 o wait4 para esperar a que el programa salga y solo luego lea el archivo. Si está utilizando un shell, otro lenguaje de programación o una biblioteca (por ejemplo, la biblioteca C sistema de llamada o la clase de proceso Java ), probablemente ya use una de estas llamadas del sistema).

Como lo han señalado otras respuestas y comentarios, puede terminar leyendo un archivo vacío después de la salida del programa si el programa ha salido sin vaciar sus memorias intermedias de salida (por ejemplo, debido a _exit , abortar o recibir una señal fatal, o porque es un programa Java que sale normalmente). Sin embargo, no hay nada que pueda hacer al respecto en este momento: los datos no vaciados se pierden para siempre, la espera adicional no los recuperará.

Sí

Perdón por tal vez agregar otra respuesta superflua, pero la mayoría parece centrarse en la pista falsa del título de la pregunta. Pero por lo que puedo decir, la pregunta no es sobre el almacenamiento intermedio, sino esto:

Cuando redirijo la salida de un comando a un archivo (por ejemplo, echo Hello> file), ¿se garantizará que ese archivo tenga esos datos justo después de que salga el comando?

Si incondicionalmente. El uso de ">" que está describiendo, junto con "|" y "<", es el modelo de procesamiento basado en tubería en el que se basa el mundo de Unix y Linux. Encontrará cientos, si no miles de scripts totalmente dependiendo de este comportamiento en cada instalación de Linux.

Funciona según lo que desee por diseño, y si hubiera la más mínima posibilidad de una condición de carrera, se habría solucionado probablemente hace décadas.