'ls' marcas de data e hora de saída diferentes para arquivos "antigos" em / tmp versus no diretório inicial

Question

Estou usando os servidores Linux da minha universidade (RHEL 7). Minha pergunta tem a ver com arquivos "ls" e "velhos".

Diretório principal:

$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2054-12-17 17:28:16.000000000 +0000 wwi-armistice
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:07:10.743637000 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:06:59.992632000 +0000 now

diretório tmp:

$ tmp=$(mktemp -d)
$ cd $tmp
$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:27.031485854 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:22.907373125 +0000 now
-rw-r--r-- 1 tsai csugrad 0 1918-11-11 11:00:00.000000000 +0000 wwi-armistice

Eu sei que a razão pela qual a primeira saída mostra wwi-armistice em 2054 tem algo a ver com a conversão de 32 bits sem assinatura de 32 bits do tempo Unix. Se alguém pudesse confirmar isso e talvez explicar por que (algo a ver com rede?), Isso seria ótimo.

Minha segunda pergunta maior é: Por que o wwi-armistice está listado corretamente quando eu faço o exemplo em / tmp?

    

Answer 1

O sistema operacional que você está executando não é suficiente para identificar a causa raiz da diferença de comportamento. O que também importa é o sistema de arquivos usado para armazenar o tempo de acesso e modificação do arquivo.

Como você adivinhou, a data errada 2054-12-17 é devida à data de destino que está sendo escrita como um inteiro de 32 bits sem sinal, mas lida como um inteiro de 32 bits assinado.

• 1918-11-11 11:00:00 = 1541934000 segundos após o tempo mínimo não assinado de 32 bits ( 1901-12-13 08:45:52 )

• 2054-12-17 17:28:16 = 1541934000 segundos após o tempo assinado máximo de 32 bits ( 2038-01-19 03:14:16 )

Seu diretório pessoal provavelmente é armazenado no NFSv3 ou em um sistema de arquivos local que armazena essas datas em 32 bits.

Por outro lado, /tmp é suportado por tmpfs , ext4 ou qualquer outro sistema de arquivos que armazene datas em 64 bits, portanto está imune ao problema.