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


21

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?


1
Voir superuser.com/a/703927/38062 pour plus d'informations. Et profitez de unix.stackexchange.com/a/304245/5132 lorsque vous utilisez debugfs.
JdeBP

1
Yay! Seulement 6 ans pour que Linus approuve :-)
Jez

ZFSenregistre également le temps de création du fichier et permet de les récupérer via des attributs étendus.
schily

Réponses:


15

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


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

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.


L'article auquel vous avez lié n'est pas disponible sans abonnement. Est-ce cet e-mail? lkml.org/lkml/2017/3/5/149 Si oui, liez-le, c'est gratuit.
Jez

@Jez corrigé. Le lien LWN sera disponible 7 jours plus tard.
sourcejedi

J'utilise le noyau 4.11.2 sur Xubuntu 17.04 avec les derniers coreutils (8.27.37-02b65a-dirty) compilés à partir de git source. stat rapporte toujours une heure de naissance vide. Qu'est-ce qui ne va pas?
2017 à 9h33

4

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.


2
Gardez à l'esprit que le temps de création dans les systèmes de fichiers qui le prennent en charge a toujours été accessible comme une statistique étendue. C'est juste que l'implémentation pour obtenir ces statistiques étendues varie beaucoup, donc il n'y a pas d'outils comme ls ou find. L'argument étant que ls devrait connaître les détails du système de fichiers pour obtenir les informations et ce n'est pas de cela qu'il s'agit.
coteyr

1
utiliser quelque chose comme debugfspour lire le champ sur l'image du disque n'est pas vraiment une interface , et il faudra de toute façon un accès privilégié.
ilkkachu

On dirait que les arguments étaient parce que l'endroit pour réellement changer cela avant l'implémentation devrait être considéré est dans POSIX lui-même. :)
Jesse Adelman

2

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


Si Linux prenait pleinement en charge, NFSv4il devrait prendre en charge les attributs étendus et il existe une entrée possible crtimedans les attributs étendus. Vérifiez par exemple la ls.csource Solaris qui imprime l'heure de création du fichier avec ls -l -% crtime.
schily

@schily, Linux a des attributs étendus et ntfs-3g tel qu'il est généralement utilisé sur les systèmes d'exploitation open source comme Linux expose en effet le temps de création NTFS en tant qu'attribut étendu, bien que depuis le 4.11, je m'attends à ce qu'il soit également disponible via statx(). Il n'y a pas encore d'utilitaire standard auquel s'interfacer statx()sous Linux, mais la récupération des attributs étendus est prise en charge depuis des décennies. Voir Comment obtenir la date de création d'un fichier sur un volume logique NTFS?
Stéphane Chazelas

Eh bien, les attributs étendus Linux sont modélisés d'après un brouillon POSIX qui a été retiré en 1997. NFSv4 définit un système d'attribut étendu moderne, qui permet de prendre en charge les flux de fichiers NTFS en tant que sous-ensemble et qui est accessible via le répertoire d'attributs du fichier ouvert via openat(fd, ".", O_RDONLY|O_XATTR).
schily

@schily, vous confondez avec les ACL ici. En effet, Linux ne prend pas encore en charge les ACL NFSv4, sauf avec un correctif non officiel, mais cela n'a pas grand-chose à voir avec les attributs étendus (sauf que les ACL seraient généralement stockées en tant qu'attributs étendus). Linux prend en charge les attributs étendus, qu'il utilise en effet pour ces ACL de type brouillon POSIX, et pour un certain nombre d'autres choses. Et l'API pour récupérer ces attributs est également utilisée par ntfs-3g pour exposer le crtime, je suppose de la même manière que sur Solaris.
Stéphane Chazelas

@schily, on dirait que vous avez ajouté de la désinformation à Wikipedia à ce sujet . S'il-vous-plaît, réparez.
Stéphane Chazelas
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.