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


21

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?


1
Vedere superuser.com/a/703927/38062 per alcuni retroscena. E goditi unix.stackexchange.com/a/304245/5132 quando stai usando debugfs.
JdeBP,

1
Sìì! Solo 6 anni per l'approvazione di Linus :-)
Jez

ZFSregistra anche i tempi di creazione dei file e consente di recuperarli tramite attributi estesi.
schily,

Risposte:


15

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


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

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.


L'articolo a cui ti sei collegato non è disponibile senza un abbonamento. È questa email? lkml.org/lkml/2017/3/5/149 In tal caso, è gratuito.
Jez

@Jez fixed. Il link LWN sarà disponibile 7 giorni dopo.
Fontejedi

Sto eseguendo il kernel 4.11.2 su Xubuntu 17.04 con gli ultimi coreutils (8.27.37-02b65a-dirty) compilati dal sorgente git. stat riporta ancora tempo di nascita vuoto. Cosa c'è che non va?
Shrx,

4

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.


2
Tieni presente che i tempi di creazione nei file system che lo supportano sono sempre stati accessibili come stat esteso. È solo che l'implementazione per ottenere quelle statistiche estese varia un po ', quindi non ci sono strumenti come ls o find. L'argomento è che dovremmo conoscere i dettagli del file system per ottenere le informazioni e non è di questo che si tratta.
Coteyr,

1
usare qualcosa come debugfsleggere il campo dall'immagine del disco non è granché un'interfaccia e avrà comunque bisogno di un accesso privilegiato.
ilkkachu,

Sembra che le argomentazioni fossero perché il posto per cambiare effettivamente questo prima che l'implementazione dovrebbe essere presa in considerazione è in POSIX stesso. :)
Jesse Adelman,

2

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


Se Linux ha supportato completamente NFSv4, dovrebbe supportare gli attributi estesi e c'è una possibile voce crtimenegli attributi estesi. Controllare ad es. L' ls.corigine Solaris che stampa il tempo di creazione del file con ls -l -% crtime.
schily,

@schily, Linux ha esteso gli attributi e ntfs-3g come in genere utilizzato su sistemi operativi open source come Linux, infatti, espone il tempo di creazione NTFS come un attributo esteso, anche se dal 4.11, mi aspetto che sia disponibile anche tramite statx(). Non esiste un'utilità standard che si interfaccia statx()ancora su Linux, ma il recupero di attributi estesi è supportato da decenni. Vedere Come ottenere la data di creazione di un file su un volume logico NTFS?
Stéphane Chazelas,

Bene, gli attributi estesi di Linux sono modellati su una bozza POSIX che è stata ritirata nel 1997. NFSv4 definisce un moderno sistema di attributi estesi, che consente di supportare flussi di file NTFS come sottoinsieme e a cui si accede tramite la directory degli attributi del file che viene aperta tramite openat(fd, ".", O_RDONLY|O_XATTR).
schily,

@schily, stai confondendo con ACL qui. In effetti, Linux non ha ancora supporto per gli ACL NFSv4, tranne che con una patch non ufficiale, ma che ha poco a che fare con gli attributi estesi (tranne per il fatto che gli ACL verrebbero normalmente memorizzati come attributi estesi). Linux supporta gli attributi estesi, che effettivamente utilizza per quegli ACL di tipo POSIX e per una serie di altre cose. E l'API per recuperare quegli attributi viene anche utilizzata da ntfs-3g per esporre il crtime, suppongo in un modo simile a quello di Solaris.
Stéphane Chazelas,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.