Isso é de fato por design. É um comportamento de longa data dos sistemas operacionais Microsoft / IBM, que também pode ser encontrado em OS / 2 de 32 bits, OS / 2 de 16 bits, PC-DOS, MS-DOS e também em DR-DOS (também conhecido como Novell DOS aka OpenDOS).
O comportamento é que a entrada de diretório de um arquivo é atualizada apenas, mostrando as informações corretas de data e hora, tamanho e alocação em uma lista de diretórios, quando uma entrada da tabela de arquivos do sistema é fechada . Uma entrada SFT é fechada quando todas as alças abertas em todos os processos que fazem referência a ela são fechadas. Programas que estão no meio do download de "centenas de MiB" ainda não fecharam suas alças de arquivos abertos. Portanto, suas entradas SFT não estão fechadas. Portanto, as entradas do diretório não são atualizadas.
If one or more additional handles to a file have been created with- "Fechando Arquivos". OS / 2 Warp: Guia de programação e referência do programa de controle . IBM Corporation.DosDupHandle, the internal buffers for the file are not written to disk, and its directory entry is not updated, untilDosClosehas been called for all the handles.
No MS / PC / DR-DOS de tarefa única, isso é um pouco difícil de observar, embora possa ser observado em DesqView, Windows 3.x no 386 Enhanced Mode, TASKMAX e assim por diante. No OS / 2 multitarefa, pode-se observá-lo com regularidade e facilidade.
Um dos recursos menos bem-vindos deste comportamento foi (em volumes FAT) que um encerramento antes de o identificador de arquivo ter sido fechado resultaria em CHKDSK vendo um arquivo de tamanho zero e truncando tudo baixado até o momento.
Este era um comportamento bem diferente do UNIX, onde era possível ver um arquivo crescer à medida que crescia com ls -l porque o comando ls olhava o nó i (na memória e atualizado) para Metadados de arquivo em vez de na entrada de diretório (que em sistemas de arquivos UNIX nativos não tem informações de tamanho e data). DOS, OS / 2 e Windows NT também estão crescendo o arquivo. Os blocos de dados estão sendo alocados no arquivo, a entrada do SFT está monitorando o tamanho do arquivo, estruturas como o nó f (em volumes HPFS) estão sendo atualizadas e, conforme você observou, o espaço livre do volume está diminuindo. Simplesmente não é possível ver, com dir ou qualquer outra coisa que relate o conteúdo da entrada de diretório , o arquivo crescendo.
A situação com o Windows NT e o NTFS é muito semelhante à situação com o OS / 2 e os DOS. (A nomenclatura foi alterada, o que é um pouco confuso para o novato. Onde DOSes e OS / 2 têm entradas de tabela de arquivos de sistema referenciados por identificadores de arquivo em processos individuais, o Windows NT tem objetos de arquivo referenciada por identificadores em processos individuais.) É, ironicamente, mais semelhante aos antigos comportamentos dos sistemas operacionais IBM / Microsoft desde o Windows NT 6.0, onde o comportamento foi alterado. O "novo" comportamento do NTFS é que as entradas de diretório de um arquivo, armazenadas em cada um dos diretórios que tem um link para o arquivo e são usadas quando alguém está listando um diretório do Win32 (com FindFirstFile / FindNextFile ), são apenas atualizado quando um objeto de arquivo para o arquivo é fechado, enquanto os metadados anexados ao arquivo em si, não visíveis em uma listagem de diretórios (e acessíveis apenas por chamadas como GetFileInformationByHandle ), são atualizados como o arquivo.
Para melhorar o risco de desligamento sujo e ver o tamanho do arquivo aumentar conforme o arquivo era gravado, um deles empregava um truque simples. Você também pode usá-lo.
A entrada de diretório de um arquivo é atualizada sempre que uma entrada da tabela de arquivos do sistema para ele é fechada, e a entrada do SFT é fechada quando o último identificador de arquivo aberto em qualquer processo que faz referência a ele é fechado. Isso não precisa ser um identificador aberto ou usado pelo processo de gravação no arquivo. Pode-se usar qualquer coisa que abra o arquivo (criando uma entrada SFT separada) e feche-a novamente. Pode ser algo tão simples quanto o comando type em execução em outro console / sessão:
type file > nulIronicamente, o Lister do Total Commander teria feito exatamente isso, toda vez que você o usasse para ver o conteúdo do arquivo enquanto ele estava sendo escrito. Se você visse isso, estaria aqui perguntando por que o Lister do Comandante Total magicamente "consertou" sua lista de diretórios. E a resposta seria que não há nada especial sobre o Total Commander. Qualquer coisa separadamente abrindo e fechando o arquivo teria o mesmo efeito.
Por questões de integridade, observe que houve chamadas do sistema que um programa de download pode usar para atualizar a entrada do diretório à medida que uma delas foi adiante. OS / 2 tem DosBufReset por exemplo. No entanto, essas chamadas de sistema também liberam o cache de disco, o que não é necessariamente o que se deseja. Abrir o arquivo pela segunda vez e depois fechar esse identificador de arquivo não libera o cache do disco.