naprawdę tak było. uważałem, że wiem co i jak i gdzie.
a potem dostałem szybką serię:
- w inode'ach są przechowywane 3 czasy. wymień je!
no to raczej proste – atime, ctime, mtime - kiedy jest modyfikowany mtime?
no … kiedy się plik zmodyfikuje. jego zawartość znaczy się. - kiedy jest zmodyfikowany atime?
przy dostępie/odczycie z pliku. - to kiedy dokładnie? przy open() czy dopiero przy read()?
ekhem. atime to “access time" czyli przy open() - kiedy jest modyfikowany ctime?
i to zasadniczo był koniec.
poczułem się jakbym grał z tmarciem w urban reign i dostał magical combosa za 70% zdrowia.
czemu? a uważacie, że odpowiedziałem dobrze? (celowo nie podałem odpowiedzi na pytanie 5, bo to dłuższa sprawa).
pytanie 1 było proste. i odpowiedziałem prawidłowo.
pytanie numer 2. – źle. nie trzeba modyfikować zawartości. zawartość może pozostać ta sama. wystarczy, że poszedł write() do tego pliku. to nawet jest logiczne – po co kernel miałby porównywać to co było w pliku z tym co jest. ale odpowiedź jest zła.
pytanie number 3 – odpowiedź nieprecyzyjna, więc dostałem kontrę – pytanie 4.
które to pytanie zwaliłem. atime zmienia się przy faktycznym odczycie danych. syscall read().
no ale ctime to była większa porażka.
najpierw uparłem się, że ctime to “creation time". co jest bzdurą. potem sobie na szczęście przypomniałem, że to jednak change time.
no a kiedy jest aktualizowane?
stwierdziłem, że gdy aktualizowany jest inode.
i to jest nieprawda.
takie wyjaśnienie ctime'a znajdziecie wszędzie. włącznie z wikipedią (więc nie tylko ja żyję w niewiedzy, ale to marne pocieszenie).
sprawdzenie tego kiedy dokładnie zmienia się ctime zajęło mi trochę czasu. mnie i rozmówcom z dwóch kanałów ircowych (#perl i #postgresql), plus grep na źródłach kernela itd.
ctime zmienia się wtedy gdy zmienia się mtime *i dodatkowo* wtedy gdy zmieniają się inne niż *time wartości w inodzie.
kilka przykładów dla lepszego zrozumienia:
- chmod i chown pliku zmieniają inode'a, więc zmienia się ctime
- zmodyfikowanie pliku (dopisanie linijki) – zmienia mtime i zmienia wielkość pliku, więc zmienia się też ctime
- zmodyfikowanie pliku (bez zmiany wielkości) – zmienia mtime więc zmienia też ctime.
to co podałem powyżej, może zasugerować, że prawdą jest, że ctime zmienia się przy zmianie danych w inodzie. ale nie.
wystarczy otworzyć plik do odczytu, odczytać coś. atime się zmienia, a ctime nie.
czyli – nie każda modyfikacja inode'a (atime jest w inodzie) modyfikuje ctime!
co zabawne. w kernelu w wersji 2.6.11 (pewnie w starszych też, i w kilku nowszych możliwe, że też), funkcja która aktualizuje mtime ma dodatkowy argument: int ctime_too. który jest potem sprawdzany i ctime jest modyfikowane tylko gdy ctime_too jest ustawione.
ale! w całych źródłach 2.6.11 (które przeszukał infi z #postgresql) wszystkie wywołania tej funkcji (inode_update_time) mają ctime_too ustawiany na 1!.
sprawdziłem źródła do 2.6.17.9 – w nich funkcja ta zmieniła nazwę na file_update_time i “zgubiła" drugi argument.
wnioski na koniec:
- kiedy uważasz, że wiesz już sporo na jakiś temat, pojawi się ktoś kto ci udowodni, że nie wiesz podstaw.
- teraz ja muszę wymyśleć jakieś pytanie by go (tego od pytań o czasy) zagiąć. jakieś pomysły?
