Kiedy przekieruję wyjście polecenia do pliku (np. echo Hello > file), Czy plik ten będzie miał gwarancję, że będzie miał takie dane zaraz po wyjściu polecenia? Czy jest jeszcze bardzo małe okno między wyjściami polecenia a danymi zapisanymi w pliku? Chciałbym przeczytać plik zaraz po wyjściu polecenia, ale nie chcę czytać pustego pliku.

W grę wchodzi wiele warstw buforów / pamięci podręcznych.

1. Pamięć podręczna procesora.

   Dane są łączone bajt po bajcie i przechowywane w pamięci podręcznej procesora. Jeśli pamięć podręczna procesora jest pełna i dane nie były dostępne przez pewien czas, blok zawierający nasze dane może zostać zapisany w pamięci głównej. Są one w większości ukryte przed programistami aplikacji.

2. Bufory procesowe.

   W procesie, w którym gromadzone są dane, jest trochę pamięci, dlatego musimy składać jak najmniej żądań do systemu operacyjnego, ponieważ jest to stosunkowo kosztowne. Proces kopiuje dane do tych buforów, które ponownie mogą być wspierane przez pamięci podręczne procesora, więc nie ma gwarancji, że dane zostaną skopiowane do pamięci głównej. Aplikacja musi jawnie opróżnić te bufory, na przykład używając fclose (3) lub fsync (3). Funkcja exit (3) robi to również przed zakończeniem procesu, podczas gdy funkcja _exit (2) nie , dlatego na stronie podręcznika jest duże ostrzeżenie, aby ta funkcja mogła ją wywołać tylko wtedy, gdy wiesz, kim jesteś robić.

3. Bufory jądra

   System operacyjny utrzymuje następnie własną pamięć podręczną, aby zminimalizować liczbę żądań, które musi wysłać na dyski. Ta pamięć podręczna nie należy w szczególności do żadnego procesu, więc dane w niej mogą należeć do procesów, które już się zakończyły, a ponieważ wszystkie przejścia przechodzą tutaj, następny program zobaczy dane, jeśli tutaj dotarł. Jądro zapisze te dane na dyskach, gdy będzie miał na to czas lub gdy zostanie wyraźnie o to poproszony.

4. Pamięć podręczna dysku

   Same dyski przechowują również pamięć podręczną, aby przyspieszyć dostęp. Są one pisane dość szybko i istnieje polecenie, aby zapisać pozostałe dane w pamięci podręcznej i zgłosić, kiedy jest to zakończone, którego system operacyjny używa podczas zamykania, aby upewnić się, że żadne dane nie zostaną niepisane przed wyłączeniem.

W przypadku aplikacji wystarczy, aby dane zostały zarejestrowane w buforach jądra (rzeczywiste dane mogą w tym momencie nadal znajdować się w pamięci podręcznej procesora i mogły nie zostać zapisane w pamięci głównej): proces „echo” kończy się, co oznacza, że ​​wszelkie bufory wewnątrzprocesowe musiały zostać opróżnione, a dane przekazane do systemu operacyjnego, a po rozpoczęciu nowego procesu gwarantuje się, że system operacyjny zwróci te same dane, gdy zostanie o to poproszony.

Jeśli aplikacja nie ma żadnych wewnętrznych pamięci podręcznych, zmiany zostaną natychmiast zapisane w pliku. To samo dla twojego przykładu. Plik jest logicznym bytem w pamięci, który zostanie natychmiast zaktualizowany. Wszelkie dalsze operacje na pliku spowodują zmiany dokonane przez program.

Nie oznacza to jednak , że zmiana została zapisana na dysku fizycznym. Zmiany mogą pozostać w pamięci podręcznej systemu plików OS lub pamięci podręcznej sprzętu. Aby opróżnić bufory systemu plików, użyj syncpolecenia.

Chciałbym przeczytać plik zaraz po wyjściu polecenia, ale nie chcę czytać pustego pliku.

Nie powinieneś mieć tutaj żadnych praktycznych problemów.

Czy bufor zostanie automatycznie opróżniony na dysk po zakończeniu procesu?

Ogólnie odpowiedź brzmi „ nie” .

To zależy od polecenia. Jak wspomniano w innych odpowiedziach, jeśli polecenie nie buforuje danych wewnętrznie, wszystkie dane będą dostępne po zakończeniu polecenia.

Ale większość, jeśli nie wszystkie, standardowe biblioteki we / wy domyślnie wykonują buforowanie standardowe (do pewnego stopnia) i dają różne gwarancje dotyczące automatycznego opróżniania buforów po zamknięciu aplikacji.

C gwarantuje, że normalne wyjście opróżni bufory . „Normalne wyjście” oznacza, że exitjest wywoływane - albo jawnie, albo przez powrót z main. Jednak nienormalne wyjście może obejść to wezwanie (a zatem pozostawić niewyłączone bufory).

Oto prosty przykład:

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

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

Jeśli to skompilować i uruchomić go, testbędzie nie muszą być zapisywane na standardowe wyjście.

Inne języki programowania dają nawet mniej gwarancje: Java, na przykład, czy nie auto-flush Po wygaśnięciu programu . Jeśli bufor wyjściowy zawiera niezakończoną linię, może zostać utracony, chyba że zostanie System.out.flush()jawnie wywołany.

To powiedziawszy, twoje pytanie pyta o coś nieco innego: jeśli dane w ogóle dotrą do pliku , powinno to zrobić natychmiast po zakończeniu polecenia (z zastrzeżeniem zastrzeżeń opisanych w innych odpowiedziach).

Myślę, że żadne pytanie nie rozwiązuje jeszcze wystarczająco tej kwestii:

Chciałbym przeczytać plik zaraz po wyjściu polecenia, ale nie chcę czytać pustego pliku.

Jak wyjaśniają inne odpowiedzi, dobrze zachowujący się program opróżnia wewnętrzne bufory plików, zanim proces zakończy się normalnie . Następnie dane mogą pozostać w buforze jądra lub sprzętu, zanim zostaną zapisane w pamięci trwałej. Jednak semantyka systemu plików w systemie Linux gwarantuje, że wszystkie procesy widzą zawartość plików w taki sam sposób, jak jądro, w tym bufory wewnętrzne ¹ .

Zwykle jest to realizowane przez posiadanie co najwyżej jednego bufora jądra na obiekt pliku i wymaganie pełnego dostępu do pliku, aby przejść przez ten bufor.

• Jeśli proces odczyta plik, jądro przedstawi zawartość bufora procesowi, jeśli żądana część pliku znajduje się obecnie w buforze; jeśli nie jest, jądro pobierze dane z podstawowego nośnika pamięci i umieści je w buforze, a następnie wróci do poprzedniego kroku.

• Jeśli proces zapisuje do pliku, dane są najpierw umieszczane w buforze jądra dla tego pliku. Ostatecznie zawartość bufora zostanie opróżniona do pamięci. Tymczasem dostęp do odczytu jest zapewniony z tego samego bufora (patrz wyżej).

¹ Przynajmniej dla zwykłych plików, katalogów i dowiązań symbolicznych. FIFO i gniazda to inna sprawa, ponieważ ich zawartość i tak nigdy nie jest przechowywana w sposób trwały. Istnieją pewne szczególne przypadki zwykłych plików, których zawartość zależy od tego, kto pyta; przykładami są pliki w procfs i sysfs (pomyśl, /proc/selfktóry jest dowiązaniem symbolicznym do identyfikatora procesu odczytującego dowiązanie symboliczne).

Zakładając, że twoje polecenie jest wykonywane przez jakiś program korzystający z biblioteki wykonawczej C, w pewnym momencie powinien on wywołać, fcloseaby zamknąć otwarty plik.

Strona podręcznika dla fclosefunkcji C mówi:

UWAGI Zauważ, że fclose () opróżnia tylko bufory przestrzeni użytkownika dostarczone przez bibliotekę C. Aby upewnić się, że dane są fizycznie przechowywane na dysku, bufory jądra również muszą zostać opróżnione, na przykład za pomocą sync (2) lub fsync (2).

a strona podręcznika dla fflushma tę samą notatkę. Strona closepodręcznika dla mówi:

Pomyślne zamknięcie nie gwarantuje, że dane zostały pomyślnie zapisane na dysk, ponieważ jądro odkłada zapis. System plików nie często opróżnia bufory, gdy strumień jest zamknięty. Jeśli chcesz mieć pewność, że dane są fizycznie przechowywane, użyj fsync (2). (W tym momencie będzie to zależeć od sprzętu dysku.)

Pamiętaj, że dane są dostępne dla innych procesów, nawet jeśli nie są zsynchronizowane z dyskiem. Może to już ci wystarczy.

W razie wątpliwości napisz test.

Kiedy przekieruję wyjście polecenia do pliku (np. echo Hello > file), Czy plik ten będzie miał gwarancję, że będzie miał takie dane zaraz po wyjściu polecenia?

Tak. Powłoka otwiera plik echowyjściowy i wysyła bezpośrednio do niego. Po wyjściu polecenia jest gotowe.

Czy jest jeszcze bardzo małe okno między wyjściami polecenia a danymi zapisanymi w pliku?

To, czy dane są już na nośniku, to inna sprawa, która ma znaczenie tylko wtedy, gdy wystąpi awaria sprzętowa, lub gdy sprawdzasz partycję na żywo za pomocą jakiegoś oprogramowania kryminalistycznego, omijając zamontowany system plików.

Chciałbym przeczytać plik zaraz po wyjściu polecenia, ale nie chcę czytać pustego pliku.

Nie martw się, jądro zachowuje tylko jeden widok pliku, niezależnie od tego, jak często jest otwierany.

Zasadniczo wszelkie dane posiadane przez jądro są utrzymywane i usuwane przez jądro, kropka. Takie dane obejmują dane przesyłane do pamięci jądra za pomocą wywołania systemowego, takiego jak write(2).

Jednakże, jeśli aplikacja (np C Library) wykonuje buforowanie na szczycie tego, wtedy jądro oczywiście nie ma pojęcia, a tym samym nie gwarantują jego oczyszczenia.

Co więcej, nie sądzę, istnieje jakikolwiek rozrządu gwarancją czystego-up-to jest na ogół wykonywana na zasadzie „best-effort” (czytaj: „kiedy mam sec”) podstawy.

Czy jest jeszcze bardzo małe okno między wyjściami polecenia a danymi zapisanymi w pliku?

Nie, nie ma.

Chciałbym przeczytać plik zaraz po wyjściu polecenia, ale nie chcę czytać pustego pliku.

Możesz przeczytać ostateczną zawartość pliku zaraz po wyjściu z polecenia, zamiast tego nigdy nie będziesz czytać pustego pliku. (W C i C ++ użyj wywołań systemowych wait , waitpid , wait3 lub wait4 , aby poczekać na zakończenie programu, a dopiero potem przeczytaj plik. Jeśli używasz powłoki, innego języka programowania lub biblioteki (np. Biblioteki C. system wywołania lub klasa Java Process ), prawdopodobnie używa już jednego z tych wywołań systemowych.)

Jak wskazały inne odpowiedzi i komentarze, możesz skończyć z czytaniem pustego pliku po wyjściu z programu, jeśli program zakończył pracę bez opróżniania wewnętrznych buforów wyjściowych (np. Z powodu wyjścia , przerwania lub odebrania krytycznego sygnału lub ponieważ program Java wychodzący normalnie). Jednak w tej chwili nic nie możesz na to poradzić : nierozpoznane dane zostaną utracone na zawsze, dodatkowe czekanie ich nie odzyska.

tak

Przepraszamy za dodanie kolejnej zbędnej odpowiedzi, ale większość wydaje się skupiać na czerwonym śledziu tytułu pytania. Ale o ile wiem, pytanie wcale nie dotyczy buforowania, ale to:

Kiedy przekieruję wyjście polecenia do pliku (np. Echo Hello> plik), czy plik ten będzie miał gwarancję, że będzie miał takie dane zaraz po wyjściu polecenia?

Tak, bezwarunkowo. Użycie opisywanego słowa „>” wraz z „|” a „<” to oparty na potokach model przetwarzania, na którym opiera się świat Unix i Linux. W każdej instalacji Linuksa znajdziesz setki, jeśli nie tysiące skryptów całkowicie zależnych od tego zachowania.

Działa tak, jak chcesz według projektu, a jeśli byłaby nawet najmniejsza szansa na wyścig, zostałby naprawiony prawdopodobnie kilkadziesiąt lat temu.