Copiei alguns diretórios para -a
os quais preserve=all
entendi que incluiriam os tempos de criação:
cp -a ./* /mnt/destination/
Ao inspecionar os diretórios resultantes no destino, todos eles têm o horário de criação definido para o horário atual,enquanto seu conteúdo parece ter preservado seus tempos de criação.
Por que as datas de criação donível superiordiretórios preservados?
A origem é HFS+ e o destino é btrfs.
Trechos de listagens de diretório de destino e origem:
$ ls -hal --time=creation
total 16K
drwxrwxr-x 1 andreas andreas 74 sep 2 23:25 .
drwx------ 1 andreas andreas 310 apr 26 17:08 ..
drwx------ 1 andreas andreas 2,3K sep 2 23:45 Library
$ ls -hal --time=creation /mnt/source
total 8,1M
drwxrwxr-x 1 andreas andreas 15 mar 28 2022 .
drwxr-x---+ 3 root root 4,0K aug 9 2022 ..
drwx------ 1 andreas andreas 95 apr 15 2019 Library
Atualizar
A julgar pelas respostas e comentários, concluí que devo ter cometido um erro ao inspecionar as datas dos subdiretórios. Eu fiz. A culpa é minha - minhas expectativas em relação ao resultado me cegaram para o que eu estava vendo. Essa parte da questão foi abandonada.
Os sistemas de arquivos unix tradicionais não possuem tempo de criação, apenas ctime. ctime é o tempo de mudança , não o tempo de criação. A hora de alteração não pode ser definida por meio de chamadas do sistema operacional, exceto para alterá-la para a hora atual. Alterar permissões ou alterar atime ou mtime definirá ctime para a hora atual.
Dito isto, parece que mesmo que o tempo de criação não faça parte do POSIX, muitos sistemas de arquivos parecem tê-lo adicionado, consulte Quais sistemas de arquivos no Linux armazenam o tempo de criação?
No entanto, mesmo para sistemas de arquivos que o suportam, ele não é padronizado; portanto, o suporte para o tempo de criação em ferramentas POSIX não é garantido e, mesmo em sistemas de arquivos que o suportam, ele pode não ser definido. Se você vê-lo definido em alguns momentos e não em outros, ou não definido de forma consistente, possivelmente várias ferramentas com suporte variado estão envolvidas ou há apenas suporte parcial nessas ferramentas.
A
statx
chamada de função específica do Linux suporta atime, btime, ctime e mtime, onde btime é marcado como horário de criação. No entanto, isso apenas lê os tempos. (Observe que vários sistemas de arquivos fazem referência ao tempo de criação de várias maneiras, incluindo hora de nascimento, btime, crtime e otime.)Indo mais fundo, gnu coreutils cp documenta o tempo de configuração por meio da
utimensat
chamada de função, que reivindica conformidade com POSIX-1.2008. Esta chamada suporta apenas a modificação de atime e mtime , mas pesquisando isso, não consegui determinar se isso ocorre porque o POSIX suporta apenas atime e mtime (com ctime não configurável) ou se é porque ctime e btime são basicamente imutáveis, alterações permitidas apenas por o sistema operacional, configurando-os para a hora atual nos eventos apropriados.Os únicos carimbos de data/hora que podem ser definidos com valores arbitrários (usando as chamadas de sistema
utime()
,utimes()
,utimensat()
, ) são o horário da última modificação, também conhecido como mtime, e o horário do último acesso, também conhecido como atime.futimens()
A hora do status de mudança, também conhecida como ctime, e hora de nascimento/criação (btime/crtime), quando suportada, não pode ser falsificada (definida arbitrariamente), portanto
cp -a
, como qualquer outro software, não é possível criar um arquivo com uma hora de nascimento diferente daquela correspondente à hora em que foi criado. foi criado.Fazer um
ln foo bar
inplacecp foo bar
ou usar a-l
opção GNUcp
resultaria embar
ter os mesmos carimbos de data e hora, incluindo o tempo de criação, quefoo
, mas observe que, nesse caso,foo
ebar
são o mesmo arquivo (com dois nomes diferentes).