No meu sistema Windows 11 22H2, verifiquei que os carimbos de data/hora do último acesso são mantidos ( fsutil behavior query disableLastAccess) e no PowerShell eles podem ser recuperados.
No entanto, com o comando cmd.exede , ou seja, exibir os arquivos pela hora do último acesso , situacionalmente parece se comportar da mesma forma que , ou seja, exibi-los pela hora da última gravação .dir/ta/tw
Isso só acontece às vezes :
Isso acontece com certos arquivos, mas parece não haver nada de especial neles (arquivos de texto apenas com o
Aconjunto de atributos).Quando isso acontece, o File Explorer também mostra o carimbo de data/hora da última gravação (mas o PowerShell sempre mostra o carimbo de data/hora correto.
Não consigo reproduzir isso de forma confiável : o código de teste do PowerShell abaixo funciona conforme esperado.
Isso está relacionado ao armazenamento de carimbos de data e hora em cache ? Mas, em caso afirmativo, por que o PowerShell é capaz de recuperá-los? Para os arquivos afetados, o problema persiste mesmo depois de algumas horas.
Código de teste do PowerShell, que não apresenta o sintoma.
# Create a test file.
1 > _test.txt
# Assign distinctive timestamps.
(Get-Item _test.txt).LastWriteTime = '1970-01-01'
(Get-Item _test.txt).LastAccessTime = '1970-01-01'
# Read the file, so as to update its last-access timestamp.
$null = Get-Content _test.txt
# List the file with its last-access timestamp.
cmd /c dir _test.txt /ta
# Do the same in PowerShell
Get-Item _test.txt | Select-Object Name, LastAccessTime
O problema pode ser que existem vários horários de último acesso. Realmente.
O artigo da Microsoft comportamento fsutil diz:
Para reduzir a sobrecarga do disco, o Windows deve manter o horário do último acesso na memória por uma hora antes de ser descarregado no disco, a fim de minimizar a E/S do disco. Então você já tem dois tempos de acesso e, dependendo da API usada, diferentes ferramentas podem reportar qualquer um dos tempos de maneira inconsistente.
A questão do último acesso foi investigada por Msuhanov no artigo
The (in)consistency of last access timestamps .
Seus resultados não foram muito encorajadores:
A gravação em disco do último horário de acesso pode ocorrer após um período de tempo muito maior que uma hora. Num caso, só foi escrito 12 horas depois, quando Msuhanov desistiu e desligou o computador. Durante esse período, um programa pode obter o horário antigo ou o novo, dependendo de como/onde está sendo obtido.
Msuhanov também descobriu que havia dois últimos tempos de acesso : um em um registro de arquivo e outro em um registro de índice ($I30). Então, dependendo da função da API de acesso, ou da função da API de modificação, estaria-se tratando de uma ou de outra, sem garantia de consistência.
Então agora temos três últimos tempos de acesso no Windows!
Minha conclusão é que a implementação do último horário de acesso no Windows é complicada e não confiável. Não sei quais desses carimbos de data e hora são usados
dir, o da memória ou o do disco. É possível quedirmostre o disco um, e isso muda quando o Windows decide gravar o da memória no disco.Eu não recomendaria confiar nos últimos horários de acesso para estar correto. Não é uma ferramenta confiável e sua implementação é estranha.