Quando reindirizzerò l'output di un comando su un file (ad es. echo Hello > file) Quel file avrà la garanzia di avere tali dati subito dopo la fine del comando? O c'è ancora una finestra molto piccola tra il comando esce e i dati scritti nel file? Vorrei leggere il file subito dopo la fine del comando, ma non voglio leggere un file vuoto.

Sono coinvolti più livelli di buffer / cache.

1. La cache della CPU.

   I dati vengono raccolti byte per byte e memorizzati nella cache della CPU. Se la cache della CPU è piena e non è stato possibile accedere ai dati per un po ', il blocco contenente i nostri dati potrebbe essere scritto nella memoria principale. Questi sono, per la maggior parte, nascosti ai programmatori dell'applicazione.

2. I buffer in-process.

   C'è un po 'di memoria messa da parte nel processo in cui vengono raccolti i dati, quindi è necessario effettuare il minor numero possibile di richieste al sistema operativo, perché è relativamente costoso. Il processo copia i dati in questi buffer, che possono essere nuovamente supportati dalle cache della CPU, quindi non è garantito che i dati vengano copiati nella memoria principale. L'applicazione deve svuotare esplicitamente questi buffer, ad esempio usando fclose (3) o fsync (3). La funzione exit (3) lo fa anche prima che il processo sia terminato, mentre la funzione _exit (2) non lo fa , motivo per cui nella pagina del manuale c'è un grande avvertimento per quella funzione per chiamarlo solo se sai cosa sei facendo.

3. I buffer del kernel

   Il sistema operativo mantiene quindi la propria cache, per ridurre al minimo il numero di richieste che deve inviare ai dischi. Questa cache non appartiene a nessun processo in particolare, quindi i dati in essa contenuti potrebbero appartenere a processi che sono già terminati e poiché tutti gli accessi passano da qui, il programma successivo vedrà i dati se sono arrivati ​​qui. Il kernel scriverà questi dati sui dischi quando avrà il tempo di farlo o quando richiesto esplicitamente.

4. La cache dell'unità

   Le unità disco stesse mantengono anche una cache per accelerare gli accessi. Questi vengono scritti abbastanza rapidamente e c'è un comando per scrivere i dati rimanenti nelle cache e riportare quando è completo, che il sistema operativo utilizza allo spegnimento per assicurarsi che nessun dato venga lasciato non scritto prima di spegnerlo.

Per la tua applicazione, è sufficiente che i dati siano registrati nei buffer del kernel (i dati effettivi potrebbero ancora vivere nella cache della CPU a questo punto e potrebbero non essere stati scritti nella memoria principale): il processo "echo" termina, che significa che tutti i buffer in-process devono essere stati cancellati e i dati consegnati al sistema operativo, e quando si avvia un nuovo processo, è garantito che il sistema operativo restituirà gli stessi dati quando richiesto.

Se l'applicazione non ha cache interne, le modifiche verranno immediatamente scritte nel file. Lo stesso per il tuo esempio. Il file è un'entità logica in memoria che verrà immediatamente aggiornata. Eventuali successive operazioni sul file vedranno le modifiche apportate dal programma.

Tuttavia , ciò non significa che la modifica sia stata scritta sul disco fisico. Le modifiche potrebbero persistere nelle cache del filesystem del sistema operativo o nelle cache hardware. Per svuotare i buffer del filesystem, utilizzare il synccomando

Vorrei leggere il file subito dopo la fine del comando, ma non voglio leggere un file vuoto.

Non dovresti incontrare problemi pratici qui.

Il buffer verrà automaticamente scaricato su disco quando termina un processo?

In generale la risposta è no .

Dipende dal comando. Come menzionano le altre risposte, se il comando non esegue il buffer interno dei dati, tutti i dati saranno disponibili al termine del comando.

Ma la maggior parte, se non tutte, le librerie I / O standard eseguono il buffer stdout per impostazione predefinita (in una certa misura) e offrono diverse garanzie sul flush automatico dei buffer alla chiusura dell'applicazione.

C garantisce che un'uscita normale svuota i buffer . "Uscita normale" significa che exitviene chiamato - esplicitamente o al ritorno da main. Tuttavia, un'uscita anomala può eludere questa chiamata (e quindi lasciare indietro i buffer non scaricati).

Ecco un semplice esempio:

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

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

Se lo compili ed eseguilo, nontest sarà necessariamente scritto su stdout.

Altri linguaggi di programmazione offrono ancora meno garanzie: Java, ad esempio, non si scarica automaticamente al termine del programma . Se il buffer di output contiene una linea non terminata, potrebbe quindi essere perso, a meno che non sia System.out.flush()stato chiamato esplicitamente.

Detto questo, il vostro corpo questione si chiede qualcosa di leggermente diverso: se i dati arrivano nel file a tutti , dovrebbe farlo immediatamente dopo le termina di comando (ferme restando le riserve descritte nelle altre risposte).

Penso che nessuna domanda affronti sufficientemente questo problema:

Vorrei leggere il file subito dopo la fine del comando, ma non voglio leggere un file vuoto.

Come spiegano le altre risposte, un programma ben funzionante scarica i suoi buffer di file interni prima che il processo si concluda normalmente . Successivamente, i dati possono ancora persistere nei buffer del kernel o dell'hardware prima di essere scritti nell'archivio permanente. Tuttavia , la semantica del file system di Linux garantisce che tutti i processi vedano il contenuto dei file nello stesso modo in cui il kernel include i buffer interni ¹ .

Questo è in genere implementato avendo al massimo un buffer nel kernel per oggetto file e per richiedere tutto l'accesso ai file per passare attraverso questo buffer.

• Se un processo legge un file, il kernel presenterà il contenuto del buffer al processo, se la parte del file richiesta è attualmente nel buffer; in caso contrario, il kernel recupererà i dati dal supporto di memorizzazione sottostante e li posizionerà all'interno del buffer, quindi tornerà al passaggio precedente.

• Se un processo scrive in un file, i dati vengono prima inseriti nel buffer interno al kernel per quel file. Alla fine il contenuto del buffer verrà scaricato nella memoria. Nel frattempo l'accesso in lettura è soddisfatto dallo stesso buffer (vedi sopra).

¹ Almeno per file regolari, directory e collegamenti simbolici. FIFO e socket sono una questione diversa poiché il loro contenuto non viene mai archiviato in modo persistente. Ci sono alcuni casi speciali di file regolari il cui contenuto dipende da chi lo sta chiedendo; esempi sono i file in procfs e sysfs (si pensi /proc/selfche sia un collegamento simbolico all'ID processo del processo che legge il collegamento simbolico).

Supponendo che il tuo comando sia eseguito da qualche programma usando la libreria di runtime C, ad un certo punto dovrebbe invocare fcloseper chiudere il file aperto.

La pagina man per la fclosefunzione C dice:

NOTE Notare che fclose () scarica solo i buffer dello spazio utente forniti dalla libreria C. Per garantire che i dati siano archiviati fisicamente su disco, anche i buffer del kernel devono essere scaricati, ad esempio con sync (2) o fsync (2).

e la pagina man per fflushha la stessa nota. La pagina man per closedice:

Una chiusura corretta non garantisce che i dati siano stati salvati correttamente su disco, come scrive il kernel defers. Non è comune per un file system svuotare i buffer quando il flusso viene chiuso. Se è necessario accertarsi che i dati siano archiviati fisicamente, utilizzare fsync (2). (A questo punto dipenderà dall'hardware del disco.)

Si noti che i dati sono disponibili per altri processi anche se non sono sincronizzati con l'unità. Forse è già abbastanza buono per te.

In caso di dubbi, scrivere un test.

Quando reindirizzerò l'output di un comando su un file (ad es. echo Hello > file) Quel file avrà la garanzia di avere tali dati subito dopo la fine del comando?

Sì. La shell apre il file di echooutput e lo invia direttamente a quello. Dopo che il comando è terminato, il gioco è fatto.

O c'è ancora una finestra molto piccola tra il comando esce e i dati scritti nel file?

Se i dati sono già presenti sul supporto è un'altra questione, che conta solo se si verifica in seguito un errore hardware o se si ispeziona la partizione live con un software forense, ignorando il filesystem montato.

Vorrei leggere il file subito dopo la fine del comando, ma non voglio leggere un file vuoto.

Non ti preoccupare, il kernel mantiene solo una vista del file, indipendentemente dalla frequenza con cui viene aperto.

Come regola generale, tutti i dati posseduti dal kernel vengono mantenuti e ripuliti dal kernel, punto. Tali dati includono i dati trasferiti nella memoria del kernel da una chiamata di sistema come write(2).

Tuttavia, se l'applicazione (ad esempio C Library) esegue il buffering sulla cima di questo, allora il kernel ha ovviamente alcuna idea e di conseguenza non garantisce il suo clean-up.

Inoltre, non credo che ci sia alcuna garanzia di tempismo per il clean-up, che è, in generale, eseguito sulla base del "miglior sforzo" (leggi: "quando ho un secondo").

O c'è ancora una finestra molto piccola tra il comando esce e i dati scritti nel file?

No, non c'è.

Vorrei leggere il file subito dopo la fine del comando, ma non voglio leggere un file vuoto.

Puoi leggere il contenuto finale del file subito dopo la fine del comando, non leggerai mai il file vuoto. (In C e C ++, utilizzare le chiamate di sistema wait , waitpid , wait3 o wait4 per attendere la chiusura del programma e solo successivamente leggere il file. Se si utilizza una shell, un altro linguaggio di programmazione o una libreria (ad esempio la libreria C sistema di chiamata o la classe di processo Java ), probabilmente utilizza già una di queste chiamate di sistema.)

Come hanno sottolineato altre risposte e commenti, potresti finire per leggere un file vuoto dopo l'uscita del programma se il programma è uscito senza svuotare i buffer di output interni (ad esempio a causa di _exit , interruzione o ricezione di un segnale fatale o perché è un programma Java che esce normalmente). Tuttavia, non c'è nulla che tu possa fare al riguardo a questo punto: i dati non scaricati vengono persi per sempre, l'attesa aggiuntiva non li ripristinerà.

sì

Scusate forse per l'aggiunta di un'altra risposta superflua, ma la maggior parte sembra concentrarsi sull'aringa rossa del titolo della domanda. Ma per quanto posso dire, la domanda non riguarda affatto il buffering, ma questo:

Quando reindirizzerò l'output di un comando su un file (ad esempio, echo Hello> file) quel file sarà garantito per avere tali dati subito dopo la chiusura del comando?

Sì, incondizionatamente. L'uso di ">" che stai descrivendo, insieme a "|" e "<", è il modello di elaborazione basato su pipe su cui il mondo Unix e Linux è fortemente basato. Troverai centinaia, se non migliaia di script totalmente dipendenti da questo comportamento in ogni installazione di Linux.

Funziona come desideri per progetto, e se ci fosse anche la minima possibilità di una condizione di gara, sarebbe stato corretto probabilmente decenni fa.