Início / computer / Perguntas / 1762090
Accepted
IsawU
Asked: 2023-01-11 02:30:13 +0800 CST

É seguro excluir um arquivo supostamente maior do que deveria ser

  • 772

Depois de chamar unrarum arquivo RAR em minha NTFSunidade de 1 TB, fico com um arquivo que supostamente tem um tamanho de 86T.

É seguro excluir esse arquivo? Qual é a melhor maneira de se livrar desse arquivo com segurança?

É claro que, quando removido, o arquivo deve ser desvinculado e quaisquer dados reais pertencentes a outros arquivos não devem ser afetados, mas eu realmente quero ter certeza disso…

Editar 1:

du -hsaída no diretório que contém o arquivo + o arquivo extraído:

26M .
Editar 2: progresso e descobertas
  • chkdsk F: /scanencontrou uma corrupção no arquivo extraído.
  • chkdsk F: /ffez Deleting corrupt attribute record (0x80, "")(provavelmente pertencente a este arquivo como o número do segmento de registro corresponde) ( atributo 0x80 )
  • O arquivo tinha tamanho 0 depois
  • O arquivo de tamanho 0 pode ser excluído
  • chkdsk F: /scannão encontra problemas
linux

2 respostas

  1. Best Answer

    Isso não é necessariamente maior do que toda a sua unidade. Muitos sistemas de arquivos, incluindo NTFS e ext4, suportam arquivos esparsos , nos quais as áreas que consistem inteiramente em bytes 'zero' ( 00 00 00 00 ...) não possuem nenhuma extensão de disco alocada para eles - tais arquivos podem facilmente ter um tamanho "aparente" maior que o sistema de arquivos, enquanto o tamanho real a alocação de dados (também conhecida como "tamanho no disco" do Windows) é menor.

    Você pode verificar se o arquivo é esparso comparando due du --apparent, listando arquivos com a ls -s/--sizeopção ou usando xfs_io para listar as extensões individuais:

    $ echo Test > large.bin
$ truncate -s 10G large.bin
$ ls -l -s
4.0K -rw-r--r-- 1 root users 10G Jan 10 12:44 large.bin

$ du -h large.bin; du -h --apparent large.bin
4.0K    large.bin
10G     large.bin

$ xfs_io -r -c "fiemap -v" large.bin 
large.bin:
 EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
   0: [0..7]:          4118216..4118223     8   0x1
   1: [8..20971519]:   hole             20971512

    Em caso de dúvida, conecte o sistema de arquivos a um sistema Windows (uma VM pode servir) e execute chkdsk X: /scanou chkdsk X: /fdeixe-o verificar se nenhum arquivo se sobrepõe - ou, após excluir o arquivo, use-o para verificar se o "bitmap de espaço livre" não discordar dos arquivos existentes.

    Em geral, os programas não seriam capazes de criar arquivos realmente maiores do que o sistema de arquivos pode acomodar: mesmo os arquivadores de arquivos não têm esse tipo de acesso direto. Se você acabar com um arquivo erroneamente grande que não é esparso, isso pode ser apenas falha do driver do sistema de arquivos do sistema operacional, caso em que nada que você faça com esse sistema de arquivos daquele ponto em diante pode ser garantido como seguro (como a exclusão é feito pelo mesmo driver "ruim", afinal). Use o CHKDSK do Windows para verificar o sistema de arquivos.

    Para NTFS no Linux, considere alternar entre os drivers integrados ntfs3e anteriores ntfs-3gpara verificar se eles se comportam da mesma forma. Tente também extrair seu arquivo em um sistema de arquivos nativo do Linux (por exemplo, no ext4) para ver se ele também cria um arquivo grande.

    • 28

  2. Caso haja algum problema com o disco, sugiro como primeiro passo garantir que você tenha backups dos dados no disco.

    Como o disco é NTFS, é melhor processá-lo no Windows da seguinte maneira.

    Como segunda etapa, execute um prompt de comando e digite o seguinte comando:

    chkdsk C:

    Se encontrar algum erro, o próximo passo será corrigir os problemas usando o comando:

    chkdsk /f C:

    Como última etapa, se tudo for concluído corretamente, você poderá excluir este arquivo.

    • 6

relate perguntas