A maioria dos sistemas Unix não rastreia os tempos de criação de arquivos. Eles rastreiam o tempo de modificação de um arquivo, que é atualizado toda vez que o arquivo é gravado. Se os arquivos forem gravados sequencialmente quando forem criados (ou seja, o primeiro arquivo for totalmente escrito antes do segundo arquivo ser criado) e não for modificado posteriormente, a ordem dos horários de modificação será igual à ordem das criações de arquivo, mas em cenários mais complexos, isso pode não ser o mesmo.
Além do tempo de modificação (mtime), existem dois outros timestamps de arquivo em qualquer sistema Unix: o tempo de acesso (atime) e o tempo de alteração do inode (ctime). O tempo de acesso é atualizado quando o arquivo é lido, mas alguns sistemas (em particular o Linux, por padrão) nem sempre o atualizam por motivos de desempenho. O tempo de alteração do inode é atualizado quando alguns metadados sobre o arquivo são alterados (nome, permissões, etc .; também quando o arquivo é gravado, mas não quando é lido, mesmo se o atime for alterado). Nem o atime nem o ctime seriam úteis para você.
Muitos sistemas Unix históricos rastrearam registros de data e hora de arquivos com uma resolução de um segundo. Os sistemas Unix modernos geralmente têm uma resolução melhor, mas isso requer que vários atores prestem atenção a isso:
- O kernel que você está usando deve suportar essa melhor resolução de tempo.
- O sistema de arquivos deve ser capaz de armazenar essa melhor resolução de tempo.
- Qualquer componente na cadeia (por exemplo, servidor NFS para um arquivo no NFS) deve suportar essa resolução de tempo mais precisa.
- Qualquer ferramenta usada para copiar os arquivos (arquivador, sincronizador de rede,…) deve ser capaz de preservar a resolução de tempo mais fina, não apenas os segundos.
- O aplicativo que lê os tempos de arquivo deve levar em consideração a resolução sub-segundo. Interfaces de programação Unix clássicas não suportam resolução sub-segundo em registros de data e hora de arquivos, portanto, os aplicativos precisam usar uma API relativamente moderna ( padronizado em POSIX: 2008 - ainda relativamente recente, pois sua adoção não foi muito rápida).
Mesmo que todos na cadeia ofereçam timestamps de nanossegundos, os arquivos terão apenas timestamps distintos se realmente forem criados com mais de um clock - só porque o kernel registra nanossegundos não garante que eles notarão < que mais de um nanossegundo passou entre as duas criações de arquivo: a leitura do relógio leva tempo, por isso não é feito o tempo todo. Se você tem um único thread abrindo o arquivo, gravando dados e fechando o arquivo antes de passar para o próximo arquivo, então, na prática, qualquer sistema de sistema existente que grave a resolução sub-segundo gravará registros de data e hora diferentes, mas você está um pequeno risco. (Quando segmentos diferentes estão gravando em arquivos, mesmo com resolução de microssegundos, colisões de timestamp são possíveis - mas normalmente, nesse caso, você não poderia confiar na ordenação de nada.)
Assim, é possível, e é confiável, desde que os computadores não sejam muito mais rápidos do que são agora, desde que todas as ferramentas que você usa suportem resolução de sub-segundo. Mas você está à mercê de um pulso de clock ou de uma ferramenta que você não tinha revisado para suporte de subsecond timestamp. Eu recomendo contar com nomes de arquivos, há menos coisas que podem dar errado.