Czy nadal nie ma interfejsu jądra systemu Linux, aby uzyskać datę utworzenia pliku?

Od dawna Linux nie zawracał sobie głowy datami tworzenia plików, ponieważ żaden z powszechnie używanych systemów plików nie obsługiwał ich. Jednak obecnie 2 powszechnie stosowane systemy plików (NTFS i ext4) rejestrują daty utworzenia plików.

statPolecenia, jednak nadal wyprowadza Birth: -na systemie plików ext4, choć widzimy, że ext4 został zapisany plik data utworzenia użyciu debugfs -R 'stat <inode_number>' /dev/file_device.

Kiedy zastanowiłem się, dlaczego tak jest, zauważyłem, że ktoś już niedawno zgłosił raport o błędzie, a odpowiedź prowadzi do problemu nadrzędnego, który po prostu stwierdza: „Obecnie nie ma interfejsu jądra systemu Linux, aby uzyskać tę informację [plik Data utworzenia]". Wydaje mi się niezwykłe, że tak jest nadal , ponieważ ludzie prosili o statwyświetlanie tych informacji od lat (i statgenerują Birthpole, chociaż najwyraźniej jeszcze go nie obsługuje! Czy dodali go w oczekiwaniu?)

Czy nadal jest prawdą, że obecnie nie ma interfejsu jądra systemu Linux, aby uzyskać datę utworzenia pliku? Czy jest jakiś plan, aby to kiedykolwiek wdrożyć?

EDYCJA: Dobra wiadomość, statx()została połączona, więc powinna być dostępna w wersji 4.11.

• https://lwn.net/Articles/716302/
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f

Praca xstat (), obecnie statx (), została poprawiona w 2016 roku.

• http://lwn.net/Articles/685791/
• http://lwn.net/Articles/686106/

Tym razem proces ten był nieco bardziej zdyscyplinowany (mniej jazdy rowerem, zgoda na odrzucenie kontrowersyjnych atrybutów, ponieważ zawsze można je później dodać). Niestety wciąż istniały zastrzeżenia do dokładnego interfejsu i nie widziałem żadnych nowych odniesień.

ponieważ żaden z powszechnie używanych systemów plików nie obsługiwał ich

Z tego, co mogę powiedzieć (przepraszam, kilka linków, pamięci i googlage, nic spójnego, by wymienić je tutaj jako odniesienie), nigdy nie było tak, ponieważ systemy podkreślające nie obsługiwały atrybutów czasu tworzenia, ale ponieważ żaden z nich nie był w stanie nawet zgadzam się, że była to przydatna funkcja.

Zobacz http://www.pathname.com/fhs/pub/fhs-2.3.html

POSIX określa trzy znaczniki czasu. Żaden z nich nie jest czasem stworzenia.

Jeśli dobrze pamiętam, argument był następujący:

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

Teraz dużo z tego to pamięć i czytanie starych list mailingowych. Tak naprawdę nie zajmowałem centralnych argumentów. Byłem na liście mailingowej z powodu pracy poza sesją w grubym sterowniku dla wbudowanego systemu Linux. Wspominam o tym, ponieważ z pewnością jest więcej autorytatywnych źródeł niż moja pamięć o czymś, na czym mi tylko zależało.

Pamiętam, że wielką rzeczą było połączenie faktu, że nikt nie mógł wymyślić dobrego przypadku użycia, nikt nie mógł zgodzić się, jak obsłużyć pole dla pozostałych 40 powszechnie używanych systemów plików, które nie obsługują czasu tworzenia, a nawet wymyślenie nazwy pola zamieniło się w masową debatę.

Czas narodzin jest w kilku natywnych systemach plików Linuksa, nie tylko ext4.

Od wersji 4.11 jądra Linuksa (kwiecień 2017 r.) Istnieje nowe statx()wywołanie systemowe, aby je pobrać. Jednak odpowiednia funkcja wrapper nie została dodana do LIBC jeszcze (od 26.06.2018. 2019 edit teraz dodanej 2.28) i narzędzi, takich jak GNU stat, ls, findnie zostały zaktualizowane, aby go używać ( 2019-08- 22 edycja GNU statw systemach GNU / Linux z wersją glibc 2.28 lub nowszą obsługuje go, ponieważ coreutils 8.31)

Możesz to zrobić za perlpomocą czegoś takiego:

perl -MPOSIX -e '
  require "syscall.ph";
  $buf = "\0" x 0x100; # enough space for a struct statx
  for (@ARGV) {
    # hardcode: AT_FDCWD == -100
    #           AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
    #           STATX_BTIME = 0x800 for the mask
    #           80: offset of the btime in the struct
    syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
      or die "$_: $!\n";
    ($t, $n) = unpack("x80QQ", $buf);
    $n = sprintf("%09d", $n);
    print strftime("%F %T.$n %z\n", localtime $t)
  }' -- "$file"

Jeśli syscall.phnie masz SYS_statx, możesz go również zakodować na stałe. Jest 332 na architekturze amd64. Lub spróbuj:

printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1

Teraz poród rzadko jest przydatny. Nie chodzi o wiek danych w pliku (dane są zapisywane w plikach po ich utworzeniu), ani niekoniecznie czas pojawienia się pliku o tej nazwie w katalogu (mógł zostać utworzony pod inną nazwą i przemianowany lub połączony tam, a treść lub atrybuty były zmieniane kilka razy pomiędzy nimi).