Como Encontrar a Data de Criação de Arquivos no Linux: Guia Técnico Completo

O Linux não expõe nativamente o tempo de criação de ficheiros através da maioria das ferramentas padrão de espaço de utilizador, mas os dados subjacentes frequentemente existem — o desafio é saber exatamente onde procurar e qual sistema de ficheiros e versão do kernel está a executar. Em sistemas de ficheiros ext4, btrfs, xfs e tmpfs com Linux kernel 4.11+, os verdadeiros timestamps de criação (crtime) são armazenados no inode e podem ser recuperados através de utilitários específicos de baixo nível. Em sistemas de ficheiros ou kernels mais antigos, deve utilizar uma combinação de metadados de inode, registos do sistema e depuradores específicos do sistema de ficheiros para aproximar o tempo de criação.

Este guia abrange todos os métodos fiáveis disponíveis em 2024, incluindo os seus pré-requisitos técnicos, sintaxe exata de comandos, modos de falha conhecidos e quando cada abordagem é adequada para administração de sistemas em produção.

Por Que o Tempo de Criação de Ficheiros no Linux Não É Simples

Cada ficheiro no Linux é descrito por um inode — uma estrutura de dados que armazena metadados como permissões, propriedade, tamanho e timestamps. O padrão POSIX definiu historicamente três timestamps:

• atime — tempo do último acesso
• mtime — tempo da última modificação (conteúdo alterado)
• ctime — tempo de alteração do inode (metadados ou conteúdo alterados)

Criticamente, ctime não é tempo de criação. Esta é uma das conceções erradas mais comuns entre administradores que migram de ambientes Windows. ctime é atualizado sempre que as permissões mudam, a propriedade muda ou o ficheiro é renomeado — não tem nada a ver com quando o ficheiro foi criado pela primeira vez.

O verdadeiro tempo de criação, conhecido como birth time ou crtime, foi adicionado à estrutura de inode do ext4 e é exposto através da chamada de sistema statx() introduzida no Linux kernel 4.11. No entanto, muitas distribuições forneceram ferramentas que não apresentavam estes dados até relativamente recentemente, razão pela qual a confusão persiste.

Pré-requisitos de Sistema de Ficheiros e Kernel

Antes de tentar qualquer método, verifique o seu ambiente:

# Check kernel version
uname -r

# Check filesystem type for a specific path
df -T /path/to/your/file

# Check filesystem mount options
findmnt -o TARGET,FSTYPE,OPTIONS /path/to/your/file

Se estiver a executar um ambiente de VPS Hosting, o sistema de ficheiros subjacente é quase sempre ext4 ou btrfs, o que significa que os dados de birth time estão disponíveis — apenas precisa das ferramentas certas para os apresentar.

Método 1: Utilizar o Comando stat (Ponto de Partida Recomendado)

O comando stat é a primeira ferramenta correta a experimentar. Em sistemas modernos com kernel 4.11+ e um sistema de ficheiros compatível, apresentará diretamente o campo Birth.

stat /path/to/your/file

Exemplo de saída num sistema ext4 moderno:

  File: /home/deploy/app/config.yml
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 2883591     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  deploy)   Gid: ( 1000/  deploy)
Access: 2024-03-15 09:22:14.812345678 +0000
Modify: 2024-03-10 14:05:33.123456789 +0000
Change: 2024-03-10 14:05:33.123456789 +0000
 Birth: 2024-03-08 11:47:02.987654321 +0000

Se o campo Birth mostrar - (um traço) em vez de um timestamp, uma das seguintes situações é verdadeira:

• O sistema de ficheiros não armazena birth time (ext2/ext3)
• O kernel é mais antigo que 4.11
• O binário stat está desatualizado e não chama statx()
• O ficheiro foi criado antes de o sistema de ficheiros ser atualizado de ext3 para ext4

Extrair apenas o timestamp de birth programaticamente:

stat --format="%w" /path/to/your/file
# Returns '-' if unavailable, or ISO 8601 timestamp if available

stat --format="%W" /path/to/your/file
# Returns Unix epoch integer (0 if unavailable)

O formato %W que retorna 0 é uma verificação programática fiável de se o birth time está genuinamente indisponível.

Método 2: Utilizar debugfs para Sistemas de Ficheiros ext4

debugfs é a ferramenta definitiva de baixo nível para inspeção de inodes ext4. Lê a estrutura de inode em bruto e pode expor crtime mesmo quando stat falha devido a um binário de espaço de utilizador mais antigo.

Passo 1: Identificar o número de inode do seu ficheiro

ls -i /path/to/your/file
# Output example: 2883591 /path/to/your/file

Passo 2: Identificar o dispositivo de bloco que aloja o sistema de ficheiros

df /path/to/your/file
# Output shows the device, e.g., /dev/sda1 or /dev/vda1

Passo 3: Consultar o debugfs com o número de inode

sudo debugfs -R 'stat <2883591>' /dev/vda1

Substitua 2883591 pelo seu número de inode real e /dev/vda1 pelo seu dispositivo real. A saída incluirá um campo crtime:

Inode: 2883591   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 3421897654    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4096
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
 atime: 0x65f4a1ae:c6b5c000 -- Fri Mar 15 09:22:14 2024
 mtime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
crtime: 0x65e4b2c6:eb851400 -- Thu Mar 08 11:47:02 2024
Size of extra inode fields: 28

Nota operacional importante: debugfs abre o sistema de ficheiros em modo apenas de leitura por padrão ao utilizar -R, mas ainda assim deve evitar executá-lo num sistema de ficheiros muito ativo sem primeiro desmontar ou utilizar um snapshot. Em Servidores Dedicados em produção, prefira sempre executar debugfs contra um snapshot do sistema de ficheiros ou um volume em repouso para evitar ler um estado de inode inconsistente.

Sintaxe alternativa utilizando o nome do ficheiro diretamente:

sudo debugfs -R "stat /path/to/your/file" /dev/vda1

Note que o caminho aqui deve ser relativo à raiz do sistema de ficheiros, não à raiz do sistema. Se /dev/vda1 estiver montado em /, então /path/to/your/file funciona como está.

Método 3: Utilizar xfs_db para Sistemas de Ficheiros XFS

Em sistemas de ficheiros XFS (comuns em sistemas RHEL/CentOS/Rocky Linux), o equivalente de debugfs é xfs_db.

# Get inode number first
ls -i /path/to/your/file

# Unmount or use read-only mode
sudo xfs_db -r /dev/sda1 -c "inode <inode_number>" -c "print"

Procure o campo v3.crtime na saída. XFS v5 (o padrão desde RHEL 7) armazena birth time nativamente. XFS v4 não.

Método 4: Utilizar Inspeção de Subvolume e Ficheiro btrfs

Em btrfs, stat com um kernel moderno é suficiente e totalmente fiável. No entanto, para inspeção mais profunda:

sudo btrfs inspect-internal dump-tree /dev/sdb | grep -A 20 "inode ref"

Para fins práticos em btrfs, o campo Birth da saída stat é autoritativo.

Método 5: Consultar statx() Diretamente via Python

Quando as ferramentas de shell fornecem resultados inconsistentes, chamar a syscall statx() diretamente do Python fornece uma resposta definitiva:

import os
import stat

result = os.stat("/path/to/your/file")
# st_birthtime is available on systems where statx() returns it
if hasattr(result, 'st_birthtime'):
    import datetime
    birth = datetime.datetime.fromtimestamp(result.st_birthtime)
    print(f"Birth time: {birth}")
else:
    print("Birth time not available on this platform/filesystem")

Para resolução mais precisa em nanossegundos, utilize o módulo ctypes para chamar statx() diretamente — isto é útil em scripts forenses onde a precisão do timestamp é importante.

Método 6: Pesquisar Registos do Sistema

Quando o birth time ao nível do sistema de ficheiros está indisponível — por exemplo, em sistemas de ficheiros ext3 ou ficheiros que antecedem uma conversão de sistema de ficheiros — os registos do sistema tornam-se a alternativa.

Pesquisar no journal do systemd:

journalctl --since="2024-01-01" | grep "your_filename"

Pesquisar no syslog tradicional:

grep "your_filename" /var/log/syslog
grep "your_filename" /var/log/messages

Pesquisar no registo de auditoria (se o auditd estiver configurado):

sudo ausearch -f /path/to/your/file

O subsistema de auditoria é o método mais fiável baseado em registos porque regista as syscalls openat(), creat() e rename() com timestamps precisos. No entanto, deve ser configurado antecipadamente — não é possível auditar retroativamente eventos de criação de ficheiros que ocorreram antes de o auditd estar ativado.

Ativar auditoria de criação de ficheiros para um diretório:

sudo auditctl -w /var/www/html -p w -k web_file_creation

Isto monitoriza /var/www/html para eventos de escrita, marcando-os com a chave web_file_creation para fácil recuperação.

Método 7: Utilizar ls — Compreender as Suas Limitações

O comando ls é frequentemente citado em guias como forma de verificar o tempo de criação, mas isto requer qualificação significativa.

ls -l --time=birth /path/to/your/file
ls -l --time=creation /path/to/your/file  # synonym on some systems

Advertência crítica: ls --time=birth só funciona no GNU coreutils 8.25+ e apenas quando o sistema de ficheiros e o kernel subjacentes suportam birth time. Se o birth time estiver indisponível, ls recorre silenciosamente a mtime sem qualquer aviso. Este recurso silencioso é um risco operacional significativo — pode acreditar que está a ler o tempo de criação enquanto na realidade está a ler o tempo de modificação.

Verifique sempre com stat primeiro. Utilize ls apenas para fins de apresentação, não para lógica em scripts.

# Safer: check stat output explicitly before relying on ls
BIRTH=$(stat --format="%W" /path/to/your/file)
if [ "$BIRTH" -eq 0 ]; then
    echo "Birth time unavailable, falling back to mtime"
    stat --format="%y" /path/to/your/file
else
    echo "Birth time: $(date -d @$BIRTH)"
fi

Comparação de Métodos e Matriz de Decisão

Casos Extremos do Mundo Real e Armadilhas

Ficheiro copiado vs. movido: Quando um ficheiro é copiado (cp), o destino obtém um novo inode com um novo birth time. Quando um ficheiro é movido dentro do mesmo sistema de ficheiros (mv), o inode é preservado e o birth time permanece inalterado. O mv entre sistemas de ficheiros comporta-se como cp + rm, criando um novo inode.

Conversão de sistema de ficheiros de ext3 para ext4: Os ficheiros que existiam antes da conversão terão um crtime de zero no seu inode, porque o ext3 nunca preencheu esse campo. debugfs mostrará crtime: 0x00000000:00000000. Neste caso, mtime no momento da conversão é a melhor aproximação.

Docker e ambientes de contentor: Os sistemas de ficheiros de contentor (overlay2, aufs) podem não propagar o birth time corretamente. Os ficheiros dentro de contentores podem mostrar o birth time como o tempo de início do contentor em vez do tempo real de criação do ficheiro.

Montagens NFS: A disponibilidade do birth time depende inteiramente do sistema de ficheiros do servidor NFS. O cliente não tem dados de birth time independentes.

Restauração de backup: Os ficheiros restaurados de arquivos tar normalmente obtêm um novo inode e, portanto, um novo birth time que reflete a data de restauração, não a data de criação original. Utilize tar --preserve-permissions e verifique mtime para a aproximação mais próxima do tempo de criação original.

Para administradores que gerem aplicações web em VPS com cPanel, a integridade dos timestamps de ficheiros é particularmente importante durante as migrações — verifique sempre os metadados de inode após restaurar a partir de backup.

Ativar Suporte a Birth Time: Ajuste do Sistema de Ficheiros

Se estiver a configurar um novo servidor e quiser suporte garantido a birth time, certifique-se do seguinte:

Para ext4 — verificar se o tamanho do inode é de 256 bytes (necessário para o campo crtime):

sudo tune2fs -l /dev/vda1 | grep "Inode size"
# Should return: Inode size: 256

Se o tamanho do inode for 128, o birth time não pode ser armazenado. Isto requer reformatação — não pode ser alterado num sistema de ficheiros existente.

Criar novo sistema de ficheiros ext4 com inodes de 256 bytes (padrão desde e2fsprogs 1.41):

sudo mkfs.ext4 -I 256 /dev/vdb1

Verificar se o kernel suporta statx():

uname -r  # Must be >= 4.11

Ao provisionar nova infraestrutura — seja Alojamento Web Partilhado ou Servidores Dedicados bare-metal — confirme o tamanho do inode do sistema de ficheiros antes de implementar aplicações que dependam de metadados de birth time.

Lista de Verificação Prática para Determinar o Tempo de Criação de Ficheiros

Utilize esta árvore de decisão quando precisar de encontrar a data de criação de um ficheiro:

• Verificar a versão do kernel primeiro: uname -r — deve ser 4.11+ para stat mostrar Birth
• Verificar o tipo de sistema de ficheiros: df -T /path/to/file — ext4, btrfs ou xfs v5 necessário
• Executar stat no ficheiro: Se o campo Birth mostrar um timestamp, tem a sua resposta
• Se Birth mostrar -: Execute debugfs (ext4) ou xfs_db (xfs) com o número de inode
• Se o sistema de ficheiros for ext3 ou ext2: Recorra a mtime como melhor aproximação
• Se precisar de precisão de nível de auditoria daqui em diante: Configure auditd agora
• Se o ficheiro foi criado recentemente: Verifique journalctl para entradas de registo corroborantes
• Em scripts: Verifique sempre stat --format="%W" para 0 antes de confiar no valor
• Após migrações ou restaurações: Trate o birth time como suspeito; faça referência cruzada com mtime e manifestos de backup

Para ambientes onde a integridade de ficheiros e a precisão de timestamps são requisitos de segurança — como aplicações que gerem Certificados SSL e ficheiros de chaves criptográficas — combinar auditd com birth time ao nível do sistema de ficheiros fornece uma abordagem de verificação em duas camadas que é defensável em auditorias de segurança.

FAQ

O Linux armazena sempre o tempo de criação de ficheiros?

Não. Apenas sistemas de ficheiros com inodes de 256 bytes (ext4, btrfs, xfs v5) armazenam birth time. ext2 e ext3 não têm um campo de birth time na sua estrutura de inode. Mesmo em sistemas de ficheiros compatíveis, os ficheiros criados antes de uma atualização do sistema de ficheiros de ext3 para ext4 terão um birth time de zero.

Qual é a diferença entre ctime e birth time no Linux?

ctime é o tempo de alteração do inode — é atualizado sempre que os metadados do ficheiro (permissões, propriedade, contagem de links) ou o conteúdo mudam. Não é o tempo de criação. O birth time (crtime) é definido uma vez quando o ficheiro é criado pela primeira vez e nunca muda. Muitos administradores confundem estes dois, o que leva a conclusões de auditoria incorretas.

Posso recuperar o tempo de criação de um ficheiro depois de ter sido perdido?

Se o campo crtime do inode for zero ou o sistema de ficheiros não o suportar, o tempo de criação original não pode ser recuperado apenas a partir do sistema de ficheiros. As suas melhores opções são: verificar os registos auditd se estiverem configurados, pesquisar registos de aplicações ou consultar manifestos de backup que registaram metadados de ficheiros no momento do backup.

Por que ls --time=creation mostra o tempo errado?

ls recorre silenciosamente a mtime quando o birth time está indisponível, sem apresentar qualquer aviso. Este é um problema comportamental conhecido no GNU coreutils. Utilize sempre stat --format="%W" para verificar programaticamente se o birth time está genuinamente disponível antes de confiar na saída de ls.

Qual comando fornece o tempo de criação de ficheiros mais fiável em ext4?

debugfs -R 'stat <inode_number>' /dev/device é o método mais fiável em ext4 porque lê a estrutura de inode em bruto diretamente, contornando quaisquer limitações de ferramentas de espaço de utilizador. Para uso diário no kernel 4.11+, stat filename com o campo Birth é equivalente e muito mais conveniente.