Ainda não existe uma interface do kernel do Linux para obter a data de criação do arquivo?

Por um longo tempo, o Linux não se preocupa com as datas de criação de arquivos, porque nenhum dos sistemas de arquivos que costumava usar os suportava. No entanto, agora, 2 sistemas de arquivos comumente usados ​​(NTFS e ext4) registram as datas de criação de arquivos.

O statcomando, no entanto, ainda gera Birth: -um sistema de arquivos ext4, embora possamos ver que o ext4 armazenou a data de criação do arquivo usando debugfs -R 'stat <inode_number>' /dev/file_device.

Quando examinei o motivo, vi que outra pessoa já havia apresentado um relatório de bug recentemente , e a resposta está vinculada a um problema inicial que simplesmente declara "não existe atualmente nenhuma interface do kernel do Linux para obter essas informações [arquivo data de criação]". Parece-me notável que aparentemente esse ainda seja o caso, pois as pessoas solicitam statessas informações há anos (e statproduzem um Birthcampo, mesmo que aparentemente ainda não o suporte ainda! Eles o adicionaram antecipadamente?)

Então, ainda é verdade que atualmente não existe uma interface do kernel Linux para obter a data de criação do arquivo? Existe um plano para implementar isso sempre?

EDIT: Boas notícias, statx()foi mesclada, portanto deve estar disponível na versão 4.11.

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

O trabalho xstat (), atualmente statx (), foi revisado em 2016.

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

O processo foi um pouco mais disciplinado dessa vez (menos ciclismo, acordo para descartar atributos controversos, pois eles sempre podem ser adicionados posteriormente). Infelizmente ainda havia objeções à interface exata e não vi nenhuma referência mais recente.

porque nenhum dos sistemas de arquivos comumente usados ​​os suportava

Pelo que posso dizer (desculpe um monte de links, memória e googlage, nada coesivo o suficiente para listar aqui como referência), nunca foi porque os sistemas subjacentes não suportavam atributos de tempo de criação, mas porque nenhum deles poderia sequer concorda que foi um recurso útil.

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

O POSIX estabelece três carimbos de hora. Nenhum deles é hora da criação.

Se bem me lembro, o argumento foi 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.

Agora, muito disso é memória e leitura de algumas listas de discussão antigas. Eu também não me sentei no centro das discussões. Eu estava em uma lista de discussão por causa de algum trabalho fora das filmagens em um driver gordo para um sistema Linux incorporado. Menciono isso porque, certamente, existem fontes mais autoritativas que minha memória de algo que eu meio que me importava.

Lembro-me de que a grande coisa é uma combinação do fato de que ninguém poderia apresentar um bom caso de uso, ninguém poderia concordar em como lidar com o campo para os outros 40 sistemas de arquivos comumente usados ​​que não suportam o tempo de criação, e até inventar um nome para o campo se transformou em um grande debate.

A hora do nascimento está em vários sistemas de arquivos nativos do Linux, não apenas no ext4.

Desde a versão 4.11 do kernel do Linux (abril de 2017), há uma nova statx()chamada do sistema para recuperá-lo. No entanto, a função de invólucro correspondente não tenha sido adicionado ao GNU libc ainda (a partir de 2018/06/26. 2019 editar agora adicionado 2,28), e ferramentas como o GNU stat, ls, findnão foram actualizadas para usá-lo ( 2019-08- 22 edit O GNU statnos sistemas GNU / Linux com glibc 2.28 ou superior suporta desde o coreutils 8.31)

Você pode fazer isso perlcom 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"

Se o seu syscall.phnão tiver SYS_statx, você também pode codificá-lo. É 332 em arquiteturas amd64. Ou tente:

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

Agora essa hora do nascimento raramente é útil. Não é a idade dos dados no arquivo (os dados são gravados nos arquivos após a sua criação), nem necessariamente a hora em que o arquivo apareceu com esse nome em um diretório (poderia ter sido criado com um nome diferente e renomeado ou vinculado lá e o conteúdo ou os atributos foram alterados várias vezes no meio).