A edição de um arquivo de texto substitui / limpa os bytes gravados no disco rígido?

0

Assim, quando você exclui um arquivo em um PC, ele remove o ponteiro daquele arquivo, em vez dos bytes reais, até que ele seja gravado.

Se você tem um txt que simplesmente tem a palavra "Olá" e eu carrego o conteúdo para "Aljoe", esta mudança é escrita sobre os bytes originais do arquivo ou simplesmente remove o ponteiro disso e cria outro arquivo de mesmos atributos mas conteúdos diferentes.

Isso significa que o arquivo "Olá" txt é recuperável ou o texto "Aljoe" substituiu esse arquivo.

Espero que isso faça sentido ...

    
por E2Busy 08.12.2017 / 15:13

2 respostas

2

Isso depende de muitos fatores - incluindo o editor escolhido, o sistema de arquivos e a tecnologia de armazenamento ...

Editor

Alguns editores simplesmente reescrevem o arquivo.

No entanto, muitos editores criarão um arquivo temporário, que é gravado até a conclusão e depois renomeado para substituir o arquivo antigo. Isso torna a operação de "salvar" atômica - ou seja, o arquivo conterá definitivamente A) o conteúdo antigo ou B) o novo conteúdo. A gravação do arquivo 'in-place' abre o potencial para arquivos parcialmente gravados ou corrupção se parte do sistema falhar (por exemplo: perda de energia ou o aplicativo trava).

Considere os seguintes pseudocódigo / etapas:

# user opens file "myfile.txt"
f = open("myfile.txt", "r")
buffer = f.read()

# user edits file in-memory

# saves file as "myfile.txt"
f = open("_myfile.txt", "w")
f.write(buffer)
f.close()
rename("_myfile.txt", "myfile.txt")

Se você está interessado em detalhes técnicos aqui, então você pode estar interessado em saber que ao usar tal editor, o ID do inode / arquivo do arquivo pode mudar a cada salvamento ... Começamos a entrar em uma discussão filosófica sobre o que " o arquivo " realmente é ... Por enquanto, vamos considerar " o arquivo " como os dados acessíveis em um local nomeado no sistema de arquivos (o nome do arquivo).

Sistema de arquivos

Mesmo que o seu editor seja "burro", e apenas reescreva o conteúdo do arquivo, o sistema de arquivos em uso é potencialmente capaz de gravar os "novos" dados em qualquer lugar que julgar adequado, e em alguns casos eles farão uma técnica semelhante à acima - escreva um novo bloco até a conclusão e, em seguida, vincule novamente a tabela de arquivos.

Isso pode ser necessário por vários motivos, incluindo a possibilidade de não haver espaço livre suficiente nesse local para os novos dados.

Tecnologia de armazenamento (disco)

Quando você considera os SSDs, as coisas vão ainda mais longe. Quando você "escreve em um local físico" em um SSD, na verdade você está escrevendo para uma área física completamente diferente do Flash, o que é completamente desconhecido para você - o SSD mantém um mapa do "físico". "para blocos" verdadeiros "físicos".

Os SSDs e outros armazenamentos flash também costumam gravar dados em páginas pré-apagadas (já que isso é mais rápido e mais conveniente) do que apagar uma determinada página para reescrevê-la. Isso também ajuda no nivelamento de desgaste; caso contrário, trabalhar em um arquivo de texto por um dia pode fazer com que as células se desgastem se o conteúdo residir nas mesmas células flash físicas.

Conclusão

Então ... com as informações que você deu, eu suspeito que é altamente improvável que simplesmente " modificando o texto em um arquivo " realmente remova o texto antigo do armazenamento persistente.

Prova

Quer experimentar por si mesmo? Execute isso no Linux:

Crie um sistema de arquivos e monte-o:

$ truncate -s $(( 10 * 1024 * 1024 )) myfs.ext2
$ mkfs.ext2 ./myfs.ext2
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks: done
Creating filesystem with 10240 1k blocks and 2560 inodes
Filesystem UUID: 42d13441-a9c1-44e1-9310-275c92c60f15
Superblock backups stored on blocks:
        8193

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

$ mkdir mnt
$ sudo mount -o loop ./myfs.ext2  ./mnt
$ sudo chown attie: ./mnt

Verifique antecipadamente se " Hello " está no que é efetivamente os dados do disco (não é):

$ grep "Hello" myfs.ext2

Escreva um " Olá " para myfile.txt no sistema de arquivos:

$ echo "Hello" > ./mnt/myfile.txt
$ sync

Verifique se " Hello " está lá agora (é):

$ grep "Hello" myfs.ext2
Binary file myfs.ext2 matches
$ cat ./mnt/myfile.txt
Hello

Escreva " Aljoe " para myfile.txt :

$ echo "Aljoe" > ./mnt/myfile.txt
$ sync

Verifique se " Hello " está lá agora (ainda está "no disco", mas não no arquivo):

$ grep "Hello" myfs.ext2
Binary file myfs.ext2 matches
$ cat ./mnt/myfile.txt
Aljoe

Isso funcionará para echo simples, mas também para vim .

Atualizar

Acabei de testar isso no Windows (que é menos disponível para mim), e parece que tanto o FAT quanto o NFTS reutilizarão o armazenamento que foi alocado, enquanto o ext2 / 3/4 alocará novo armazenamento.

Além disso, uma revisão rápida do Notepad ++ e Atom mostra que a abordagem "gravar e renomear" não é usada como eu esperava - enquanto é usada por aplicativos como vim .

Acho que uma resposta mais correta pode ser:

  • Se você estiver executando o Windows, os dados provavelmente serão sobrescritos imediatamente.
  • Se você estiver executando o Linux, os dados provavelmente permanecerão no armazenamento persistente.

" Provavelmente ", porque há exceções, claro, para essas declarações.

    
por 08.12.2017 / 15:24
-1

Não posso ter certeza absoluta, mas tenho certeza de que, com 99% de certeza, o texto original será sobrescrito e eliminado. Se você tentou um programa de undelete, eu acho que não vai conseguir porque os bytes são sobrescritos. Programas Undelete não são conhecidos por obter revisões anteriores de um arquivo! Se ele excluir um ponteiro para dados antigos e armazenar novos dados em outro lugar, eles serão conhecidos por obter revisões anteriores de um arquivo! Ou as pessoas não recuperariam um arquivo e teriam que escolher qual versão, ou obteriam uma versão de um arquivo de uma gravação anterior, da qual nunca se ouve.

    
por 08.12.2017 / 16:18