¿Todavía no hay una interfaz de kernel de Linux para obtener la fecha de creación del archivo?

Durante mucho tiempo, Linux no se ha molestado con las fechas de creación de archivos porque ninguno de los sistemas de archivos que usaba comúnmente los admitía. Sin embargo, ahora, 2 sistemas de archivos de uso común (NTFS y ext4) registran ambas fechas de creación de archivos.

El statcomando, sin embargo, todavía sale Birth: -en un sistema de archivos ext4, aunque podemos ver que ext4 ha almacenado la fecha de creación del archivo usando debugfs -R 'stat <inode_number>' /dev/file_device.

Cuando analicé por qué es así, vi que alguien más ya había presentado un informe de error al respecto, y la respuesta se vincula a un problema ascendente que simplemente dice "actualmente no hay una interfaz de kernel de Linux para obtener esa información [archivo fecha de creación]". Me parece notable que aparentemente este sigue siendo el caso, ya que la gente ha estado solicitando que statmuestre esta información durante años (¡y statgenera un Birthcampo, aunque aparentemente todavía no lo admite! ¿Lo agregaron anticipadamente?)

Entonces, ¿sigue siendo cierto que actualmente no hay una interfaz de kernel de Linux para obtener la fecha de creación del archivo? ¿Hay algún plan para implementar esto alguna vez?

EDITAR: Buenas noticias, statx()se ha fusionado, por lo que debería estar disponible en la versión 4.11.

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

El trabajo xstat (), actualmente statx (), se revisó en 2016.

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

El proceso fue un poco más disciplinado esta vez (menos bikeshedding, acuerdo para eliminar atributos controvertidos, ya que siempre se pueden agregar más adelante). Desafortunadamente, todavía hubo objeciones a la interfaz exacta y no he visto más referencias recientes.

porque ninguno de los sistemas de archivos que usaba comúnmente los soportaba

Por lo que puedo decir (perdón por un montón de enlaces, memoria y Google, nada lo suficientemente coherente como para enumerar aquí como referencia), nunca fue porque los sistemas de subrayado no admitían atributos de tiempo de creación, sino porque ninguno de ellos podía siquiera Estoy de acuerdo en que era una característica útil.

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

POSIX presenta tres marcas de tiempo. Ninguno de ellos es tiempo de creación.

Si no recuerdo mal, el argumento fue algo como:

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

Ahora, mucho de esto es memoria y leer algunas listas de correo antiguas. Realmente tampoco me sentí central en los argumentos. Estaba en una lista de correo debido a un poco de trabajo de rodaje en un controlador gordo para un sistema Linux incorporado. Menciono eso porque seguramente hay más fuentes autorizadas que mi memoria de algo que solo me importaba.

Recuerdo que el gran problema es una combinación del hecho de que nadie podría llegar a un buen caso de uso, nadie podría ponerse de acuerdo sobre cómo manejar el campo para los otros 40 sistemas de archivos de uso común que no admiten el tiempo de creación, e incluso crear un nombre para el campo se convirtió en un debate masivo.

La hora de nacimiento es en varios sistemas de archivos nativos de Linux, no solo ext4.

Desde la versión 4.11 del kernel de Linux (abril de 2017), hay una nueva statx()llamada al sistema para recuperarlo. Sin embargo, la función de contenedor correspondiente no ha sido añadido a la GNU libc todavía (a partir del 26/06/2018. 2019 edición añade ahora en 2,28), y herramientas como GNU stat, ls, findno se han actualizado para usarlo ( 2019-08- 22 editar GNU staten sistemas GNU / Linux con glibc 2.28 o superior lo admite desde coreutils 8.31)

Sin embargo, podría hacerlo perlcon algo como:

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 syscall.phno tiene SYS_statx, también puede codificarlo. Es 332 en arquitecturas amd64. O tratar:

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

Ahora ese tiempo de nacimiento rara vez es útil. No es la antigüedad de los datos en el archivo (los datos se escriben en los archivos después de haber sido creados), ni necesariamente el momento en que el archivo apareció con ese nombre en un directorio (podría haberse creado con un nombre diferente y renombrado o vinculado allí y el contenido o los atributos se han cambiado varias veces en el medio).