Existem 3 tipos de “carimbos de data / hora”:

• Acesso – o último hora em que o arquivo foi lido
• Modificar – a última vez que o arquivo foi modificado (o conteúdo foi modificado)
• Alterar – a última vez que os metadados do arquivo foram alterados (por exemplo, permissões)

Para exibir essas informações, você pode usar stat que faz parte dos coreutils.

stat também mostrará mais alguns informações como dispositivo, inodes, links, etc.

Lembre-se de que esse tipo de informação depende muito do sistema de arquivos e das opções de montagem. Por exemplo, se você montar uma partição com a opção noatime, nenhuma informação de acesso será gravada.

Um utilitário para alterar os carimbos de data / hora seria touch. Existem alguns argumentos para decidir qual carimbo de data / hora alterar (por exemplo, -a para tempo de acesso, -m para tempo de modificação) e para influenciar a análise de um novo carimbo de data / hora. Consulte man touch para obter mais detalhes.

touch pode ser útil em combinação com cp -u ( “copiar apenas quando o arquivo SOURCE for mais recente que o arquivo de destino ou quando o arquivo de destino estiver ausente” ) ou para a criação de arquivos de marcador vazios.

Comentários

• Obrigado! Para o comando rsync, em ” ele não ‘ se importa com qual arquivo é mais recente “, em termos de qual tipo de carimbo de data / hora significa ” mais recente “. Além disso, em uma observação lateral, o tipo de arquivo com o qual o rsync se preocupa significa apenas arquivo regular e simlink, não o tipo como pdf, jpg, htm, txt etc?
• Geralmente, referência ao tempo de um arquivo é o carimbo de data / hora ” modificado “. Por exemplo, o que você vê em ls -l. E o tipo de arquivo se refere a arquivo vs. link simbólico (ou outros tipos de arquivos como diretórios ou dispositivos). Não o tipo de dados no arquivo (texto vs. jpeg, etc.).
• @Tim Nesse contexto, ‘ sa timestamp modificado; rsync está dizendo que quando ‘ está decidindo se deve fazer backup de um arquivo, ele não ‘ verifica se o arquivo fonte foi modificado mais recentemente do que o backup existente (o que é comum com programas de backup); ele apenas verifica se os arquivos têm tamanhos diferentes ou tempos de modificação diferentes e faz backup se sim
• E como eu sei quando o arquivo foi criado primeiro? Essas informações são mantidas em algum lugar ou perdidas nas atualizações? por assim dizer, há quanto tempo o arquivo existe ..?
• A página do manual stat (2) descreve em mais detalhes quando esses carimbos de data / hora são alterados.

A resposta de echox é válida, mas eu quero adicionar informações sobre o arquivo hora de criação.

Suporte ao sistema de arquivos

Alguns sistemas de arquivos suportam uma entrada adicional no inode referente à hora de criação (ou hora de nascimento). Eu sei que ext4 oferece suporte a esse recurso e também JFS e BTRFS .

No entanto, a maioria das ferramentas e API ainda não foram atualizadas para ler essas informações extras.Portanto, embora pudesse estar lá, “não está acessível.

Por exemplo, no Ubuntu 12.04 LTS, recebo o seguinte para um arquivo que criei hoje:

$ echo Just another test > /tmp/mytest $ sleep 3 $ touch /tmp/mytest $ sleep 2 $ cat /tmp/mytest > /dev/null $ stat /tmp/mytest [...] Access: 2012-06-05 13:33:44.279774711 +0200 Modify: 2012-06-05 13:33:34.611893317 +0200 Change: 2012-06-05 13:33:34.611893317 +0200 Birth: - $ sudo debugfs -R "stat /tmp/mytest" /dev/sda1 [...] ctime: 0x4fcdee8e:91e30114 -- Tue Jun 5 13:33:34 2012 atime: 0x4fcdee98:42b417dc -- Tue Jun 5 13:33:44 2012 mtime: 0x4fcdee8e:91e30114 -- Tue Jun 5 13:33:34 2012 crtime: 0x4fcdee46:01258f1c -- Tue Jun 5 13:32:22 2012 [...] 

Você pode ver que a função stat mais recente tem um campo de nascimento, embora a saída pareça incorreta. E através do debugfs podemos obter as informações (crtime como estou no sistema de arquivos ext4).

suporte statx

Existe agora desde o Kernel 4.11, uma nova chamada de sistema statx , além do melhor suporte do Y2038 ou da rede sistemas de arquivos, ele também traz alguns recursos extras, como o btime ou acesso à hora do nascimento (hora da criação). O suporte para ext4 deve estar no mesmo kernel versão 4.11.

Houve patches para adicionar suporte a este novo syscall em versões posteriores do Kernel: por exemplo, BTRFS e F2FS no Kernel 4.13, SMB3 no 4.14, GFS2 no 4.15, NFS no 4.16, etc.

O glibc que está por vir fornecerá uma chamada de função para consultar esta interface (consulte Notícias da Phoronix sobre o suporte glibc statx ). Portanto, podemos esperar suporte para esse recurso no espaço do usuário em breve.

Comentários

• Você sabe se o btime permanece intacto quando os arquivos do Windows (Criação time) são movidos para ext4 e vice-versa, como mtime?
• @paradroid desculpe, eu não sei a resposta. Se você quer dizer no Linux ao copiar um arquivo do NTFS para o ext4, seria necessário olhar o driver NTFS se ele suporta o tempo de criação. Se você quer dizer no Windows, seria necessário procurar no driver ext4 para Windows.