N'y a-t-il toujours pas d'interface du noyau Linux pour obtenir la date de création du fichier?

Depuis longtemps, Linux ne s'est pas soucié des dates de création de fichiers car aucun des systèmes de fichiers qu'il utilisait couramment ne les supportait. Cependant maintenant, 2 systèmes de fichiers couramment utilisés (NTFS et ext4) enregistrent tous deux des dates de création de fichiers.

La statcommande, cependant, toujours en sortie Birth: -sur un système de fichiers ext4, même si nous pouvons voir que ext4 a stocké le fichier de la date de création à l' aide debugfs -R 'stat <inode_number>' /dev/file_device.

Quand j'ai cherché à savoir pourquoi cela s'est produit, j'ai vu que quelqu'un d'autre avait déjà récemment déposé un rapport de bogue à ce sujet, et la réponse est liée à un problème en amont qui indique simplement "il n'y a pas d'interface de noyau Linux actuellement pour obtenir cette information [fichier date de création]". Il me semble remarquable que cela soit apparemment toujours le cas, car les gens demandent à statafficher ces informations depuis des années (et statproduisent un Birthchamp, même s'il ne le supporte apparemment pas encore! L'ont-ils ajouté par anticipation?)

Est-il donc toujours vrai qu'il n'y a pas d'interface de noyau Linux actuellement pour obtenir la date de création du fichier? Existe-t-il un plan pour mettre cela en œuvre?

EDIT: Bonne nouvelle, statx()a été fusionnée et devrait donc être disponible dans la version 4.11.

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

Le travail xstat (), actuellement statx (), a été révisé en 2016.

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

Le processus a été un peu plus discipliné cette fois (moins de bikeshedding, accord pour abandonner les attributs controversés car ils peuvent toujours être ajoutés plus tard). Malheureusement, il y avait encore des objections à l'interface exacte et je n'ai vu aucune référence plus récente.

car aucun des systèmes de fichiers qu'il utilisait couramment ne les supportait

D'après ce que je peux dire (désolé un tas de liens, de mémoire et de googlage, rien de suffisamment cohérent pour être répertorié ici comme référence), ce n'est jamais parce que les systèmes de soulignement ne prenaient pas en charge les attributs de temps de création, mais parce qu'aucun d'entre eux ne pouvait même conviennent que c'était une caractéristique utile.

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

POSIX dispose de trois horodatages. Aucun d'eux n'est le temps de la création.

Si je me souviens bien, l'argument est allé quelque chose comme:

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

Maintenant, beaucoup de cela est de la mémoire et de la lecture de vieilles listes de diffusion. Je n'étais pas non plus au centre des arguments. J'étais sur une liste de diffusion à cause d'un travail hors tournage dans un gros pilote pour un système Linux embarqué. Je mentionne cela parce qu'il y a sûrement plus de sources faisant autorité que ma mémoire de quelque chose dont je me souciais un peu.

Je me souviens que le gros problème était une combinaison du fait que personne ne pouvait proposer un bon cas d'utilisation, personne ne pouvait s'entendre sur la façon de gérer le champ pour les 40 autres systèmes de fichiers couramment utilisés qui ne prennent pas en charge le temps de création, et même trouver un nom pour le domaine s'est transformé en un débat massif.

L'heure de naissance est dans plusieurs systèmes de fichiers natifs Linux, pas seulement ext4.

Depuis la version 4.11 du noyau Linux (avril 2017), il y a un nouvel statx()appel système pour le récupérer. Cependant, la fonction enveloppe correspondant n'a pas été ajouté à la GNU libc encore (au 26/06/2018. 2019 modifier maintenant ajouté à 2,28), et des outils tels que GNU stat, ls, findn'ont pas été mis à jour pour l' utiliser ( 2019-08- 22 Modifier GNU statsur les systèmes GNU / Linux avec glibc 2.28 ou supérieur le supporte depuis coreutils 8.31)

Vous pouvez le faire perlavec quelque chose comme:

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"

Si ce syscall.phn'est pas le cas SYS_statx, vous pouvez également le coder en dur. C'est 332 sur les architectures amd64. Ou essayez:

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

Maintenant que l'heure de naissance est rarement utile. Ce n'est pas l'âge des données dans le fichier (les données sont écrites dans des fichiers après leur création), ni nécessairement l'heure à laquelle le fichier est apparu sous ce nom dans un répertoire (il aurait pu être créé sous un nom différent et renommé ou lié) et le contenu ou les attributs ont été modifiés plusieurs fois entre les deux).