Existem três carimbos de tempo nos sistemas Unix:
-
atime
: tempo de acessoEste registro de data e hora informa quando o arquivo foi acessado na última vez, incluindo apenas o acesso de leitura.
-
ctime
: tempo de alteraçãoEste registro de data e hora informa quando os atributos do arquivo (inode information) foram alterados na última vez. Isso inclui, por exemplo, propriedade e permissões, mas uma alteração de conteúdo também aciona uma atualização desse registro de data e hora.
Observe que as alterações no atime parecem ser uma exceção , pois não acionam uma atualização do ctime. Provavelmente, isso ocorre porque um simples acesso de leitura, que é suficiente para acionar uma atualização atime, não faz alterações relevantes nos atributos do arquivo. E um dos principais objetivos da ctime é ajudar as ferramentas de backup a determinar se um arquivo foi alterado. O atime é uma informação irrelevante para tais ferramentas e atualizar um backup apenas para atualizar um atime alterado porque alguém leu o arquivo seria inútil.
Não tenho certeza, mas algumas pessoas acham que esse comportamento (alterações no atime não atualizam o ctime) é devido apenas às opções de montagem (comorelatime
) do sistema de arquivos subjacente que armazena em cache e atrasa o atime atualiza no inode por razões de performance na memória e só os aplica aos inodes reais no disco (disparando uma atualização ctime) sob certas condições.
@kos tentou e aparentemente mesmo quando montou um FS com o 'strictatime''option, o ctime parece nunca atualizar se o atime mudar. -
mtime
: tempo de modificaçãoEste registro de data e hora informa quando o conteúdo do arquivo foi modificado na última vez.
Portanto, um acesso de leitura simples usando cat FILENAME
altera apenas o atime , mas não o ctime , pois nenhum atributo de arquivo foi modificado. O atime alterado não conta.