Non esiste ancora un'interfaccia del kernel Linux per ottenere la data di creazione del file?

Per molto tempo, Linux non si è preoccupato delle date di creazione dei file perché nessuno dei file system comunemente usati li supportava. Tuttavia ora, 2 file system comunemente usati (NTFS ed ext4) registrano entrambe le date di creazione del file.

Il statcomando, tuttavia, continua a essere emesso Birth: -su un file system ext4, anche se possiamo vedere che ext4 ha memorizzato la data di creazione del file usando debugfs -R 'stat <inode_number>' /dev/file_device.

Quando ho esaminato il perché, ho visto che qualcun altro ha già recentemente presentato un bug report e la risposta si collega a un problema a monte che afferma semplicemente "al momento non esiste un'interfaccia del kernel Linux per ottenere tali informazioni [file data di creazione]". Mi sembra straordinario che questo sia apparentemente ancora vero, dal momento che la gente ha richiesto che statvisualizzasse queste informazioni per anni (e statproduce un Birthcampo, anche se apparentemente non lo supporta ancora! L'hanno aggiunto in anticipo?)

Quindi è ancora vero che al momento non esiste un'interfaccia del kernel Linux per ottenere la data di creazione del file? C'è un piano per implementarlo mai?

EDIT: Buone notizie, statx()è stato unito quindi dovrebbe essere disponibile nella versione 4.11.

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

xstat () work, attualmente statx (), è stato rivisto nel 2016.

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

Questa volta il processo è stato un po 'più disciplinato (meno bikeshedding, accordo per abbandonare attributi controversi in quanto possono sempre essere aggiunti in seguito). Sfortunatamente c'erano ancora obiezioni all'interfaccia esatta e non ho visto riferimenti più recenti.

perché nessuno dei file system comunemente usati li supportava

Da quello che posso dire (scusate un sacco di collegamenti, memoria e googlage, niente di abbastanza coerente da elencare qui come riferimento), non è mai stato perché i sistemi di sottolineatura non supportavano gli attributi del tempo di creazione, ma perché nessuno di loro poteva nemmeno concordo sul fatto che fosse una funzione utile.

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

POSIX stabilisce tre timestamp. Nessuno di loro è tempo di creazione.

Se ricordo bene l'argomento è andato qualcosa del tipo:

> 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.

Gran parte di questo è memoria e lettura di alcune vecchie mailing list. Nemmeno io sono rimasto al centro degli argomenti. Ero su una mailing list a causa di alcuni lavori off-shoot in un grosso driver per un sistema Linux incorporato. Lo dico perché poiché ci sono sicuramente più fonti autorevoli della mia memoria di qualcosa a cui tenevo solo un po '.

Ricordo che il grosso problema era una combinazione del fatto che nessuno poteva trovare un buon caso d'uso, nessuno poteva concordare su come gestire il campo per gli altri 40 file system comunemente usati che non supportano i tempi di creazione, e persino trovare un nome per il campo si è trasformato in un grande dibattito.

Il tempo di nascita è in diversi file system nativi Linux, non solo ext4.

Dalla versione 4.11 del kernel Linux (aprile 2017), c'è una nuova statx()chiamata di sistema per recuperarlo. Tuttavia, la funzione wrapper corrispondente non è stato aggiunto alla GNU libc ancora (come del 2018/06/26. 2019 Modifica ora aggiunto a 2.28), e strumenti come GNU stat, ls, findnon sono stati aggiornati per usarlo ( 2019-08- 22 modifica GNU statsu sistemi GNU / Linux con glibc 2.28 o successivo lo supporta dal coreutils 8.31)

Potresti farlo anche perlse con qualcosa del tipo:

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"

Se syscall.phnon lo hai SYS_statx, puoi anche codificarlo. È 332 su architetture amd64. Oppure prova:

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

Ora che il tempo di nascita è raramente utile. Non è l'età dei dati nel file (i dati vengono scritti nei file dopo che sono stati creati), né necessariamente l'ora in cui il file è apparso con quel nome in una directory (potrebbe essere stato creato con un nome diverso e rinominato o collegato lì e il contenuto o gli attributi sono stati cambiati più volte in mezzo).