Eu apenas sei que ls -t
e ls -f
fornece uma classificação diferente de arquivos e subdiretórios em um diretório.
Por exemplo, vi alguém escrever:
Por padrão, o programa rsync procura apenas ver se os arquivos têm tamanho e carimbo de data/hora diferentes. Não importa qual arquivo é mais novo; se for diferente, ele será sobrescrito. Você pode passar o sinalizador '--update' para o rsync, o que fará com que ele ignore os arquivos no destino, se forem mais novos que o arquivo na fonte, mas apenas enquanto forem do mesmo tipo de arquivo. O que isso significa é que, por exemplo, se o arquivo de origem for um arquivo regular e o destino for um link simbólico, o arquivo de destino será substituído, independentemente do carimbo de data/hora.
Em uma nota lateral, o tipo de arquivo aqui significa apenas arquivo regular e simlink, não o tipo como pdf, jpg, htm, txt etc?
Existem 3 tipos de "timestamps":
Para exibir essas informações, você pode usar stat
, que faz parte dos coreutils.
stat
mostrará também mais algumas informações como o 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 registros de data e hora seria touch
. Existem alguns argumentos para decidir qual carimbo de data e hora alterar (por exemplo, -a para horário de acesso, -m para horário de modificação) e influenciar a análise de um novo carimbo de data/hora. Vejo man touch
para mais detalhes.
touch
pode ser útil em combinação com cp -u
( "copia somente quando o arquivo SOURCE é mais novo que o arquivo de destino ou quando o arquivo de destino está ausente" ) ou para a criação de um marcador vazio arquivos.
A resposta do echox é válida, mas quero adicionar informações sobre o tempo de criação do arquivo.
Alguns sistemas de arquivos suportam uma entrada adicional no inode em relação à hora de criação (ou hora de nascimento). Eu sei que ext4 suporta esse recurso e também JFS e BTRFS .
No entanto, a maioria das ferramentas e da API ainda não foram atualizadas para ler essas informações extras. Portanto, mesmo que possa estar lá, não é 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 possui um campo de nascimento, embora a saída pareça incorreta. E via debugfs, podemos obter as informações (crtime, como estou no sistema de arquivos ext4).
Agora existe desde o Kernel 4.11 uma nova chamada de sistema statx , além de um melhor suporte ao Y2038 ou sistemas de arquivos de rede, ele também traz alguns recursos extras, como o btime
ou a hora do nascimento ( hora de criação). O suporte ao ext4 deve estar na mesma versão 4.11 do kernel.
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 em 4.14, GFS2 em 4.15, NFS em 4.16, etc.
A próxima glibc fornecerá uma chamada de função para consultar esta interface (consulte Notícias do Phoronix sobre o suporte à glibc statx ). Portanto, podemos esperar suporte para esse recurso no espaço do usuário em breve.