Durante muito tempo, o Linux não se importou com as datas de criação de arquivos, porque nenhum dos sistemas de arquivos usados normalmente os suportavam. No entanto, agora, dois sistemas de arquivos comumente usados (NTFS e ext4) registram as datas de criação do arquivo.
O comando stat , no entanto, ainda gera Birth: - em 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 analisei por que isso acontece, vi que outra pessoa já havia arquivado recentemente questão de upstream que simplesmente afirma "não há uma interface de kernel do Linux para obter essa informação [data de criação do arquivo]". Parece notável para mim que isso ainda é ainda o caso, já que as pessoas têm solicitado que stat exiba essas informações por anos (e stat produz um campo Birth , mesmo que aparentemente não suporta ainda! Eles adicionaram isso em antecipação?)
Então, ainda é verdade que não há interface de kernel do Linux para obter a data de criação do arquivo? Existe um plano para implementar isso sempre?
EDIT: Boas notícias, statx() foi mesclado, por isso deve estar disponível na versão 4.11.
xstat (), atualmente statx (), foi revisado em 2016.
O processo foi um pouco mais disciplinado desta vez (menos bikeshedding, acordo para deixar cair atributos controversos, pois eles sempre podem ser adicionados mais tarde). Infelizmente ainda houve objeções à interface exata e não vi nenhuma referência mais recente.
because none of the file systems it commonly used supported them
Pelo que eu posso dizer (desculpe um monte de links, memória e googlage, nada coeso o suficiente para listar aqui como referência), nunca foi porque os sistemas de sublinhado não suportavam atributos de tempo de criação, mas porque nenhum dos eles poderiam até concordar que era um recurso útil.
Veja o link
POSIX estabelece três carimbos de hora. Nenhum deles é tempo de 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 como central nos argumentos. Eu estava em uma lista de discussão por causa de algum trabalho fora de tiro em um driver de gordura para um sistema Linux embarcado. Eu menciono isso porque há certamente mais fontes autorizadas do que a minha memória de algo que eu só me importava.
Eu lembro que o grande negócio é uma combinação do fato de que ninguém poderia criar 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 tempo de criação, e até mesmo chegando com um nome para o campo se transformou em um enorme debate.
A hora de nascimento está em vários sistemas de arquivos nativos do Linux, não apenas ext4.
Desde a versão 4.11 do kernel do Linux (abril de 2017), há um novo < href="http://man7.org/linux/man-pages/man2/statx.2.html"> statx() chamada de sistema para recuperá-la. No entanto, a função wrapper correspondente não foi adicionada ao GNU libc ainda (a partir de 2018-06-26. 2019 edit agora adicionada em 2.28), e ferramentas como o GNU stat , ls , find não foram atualizados para usá-lo.
Você poderia fazer isso em perl com algo como:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1
" 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.ph não tiver SYS_statx , você poderá codificá-lo também. É 332 em arquiteturas AMD64. Ou tente:
perl -MPOSIX -e '
require "syscall.ph";
$buf = "printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1
" 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"
Agora que o horário de nascimento raramente é útil. Não é a idade dos dados no arquivo (os dados são gravados em arquivos após terem sido criados), nem necessariamente a hora em que o arquivo apareceu por esse nome em um diretório (poderia ter sido criado como um nome diferente e renomeado ou vinculado lá e o conteúdo ou atributos foram alterados várias vezes entre eles).
Tags stat filesystems