Writing data over the data of a file is not "safe" - and the reason is that it depends on the filesystem layer (F.S.) of the operating system to decide what to do when you open a file to write - and if you see, none of them, for various reasons, will record the data at the same physical position of the disk on which the previous data were.
The idea that when opening a file for reading and writing, you can modify a single byte of the file, close, and read again and have all the original data with that 1 byte different, is convenient for programs at high level, but it is only an abstraction of the operating system.
In practice, because of how disk data access has evolved historically, the system can only write blocks of at least 512 bytes - but most likely 4Kbytes (4096) at once - which is done when you modify a single byte is:
- the lowest layers of the S.O. read 4KB of the disk (even if the file is smaller, any dirt that is on the disk after the arqiuvo is read to memory)
- the S.O. highest-level layer changes the desired byte within that block
- the 4KB are returned to the disc, but not in the same position
- if all went well so far, the F.S. layer of the operating system changes the file metadata to read the 4KB of the new position, not the old one. (mainly in modern F.S. which has a journaling mencanism - which allows the old version of the file to be read, if any failure happens before the end of the whole process).
Any tool that has access to the raw data on the disk partition can then access the "over-written" file data. It can take a good job to reconstruct these files from the pieces found - and many parts may be physically over-written, by the very process of rewriting the files, but it is more to "chance" than deliberate destruction.
If you are on a Linux operating system, the raw partition data is accessible simply by opening the special devices on /dev/
as if they were normal files. (In this case, read and write in those device files, yes, makes bytes read and written at the same physical disk positions - precisely why the filesystem code used by the kernel to access physical devices as files does this)
So, if you have any special bibliotca, that can understand the data structure of the particular filesystem that you intend to change, it is possible, according to the "raw" (raw) device, to write the exact bytes, irreversibly, of the files, as you want.
The work to do this correctly is at least an order of magnitude more complex than just using the user layer to open and record arches, as you want to do. (some filesystems are so complex that dozens of the best devs in the world took more than 10 years to access their data directly correctly in a parallel implementation - see the history of NTFS drivers on Linux, for example, or ZFS). But if it’s a FAT, or FAT 32 - still used on some USB drives, it’s more or less quiet to redo the access, and it can be a pretty fun project. (But on USB drives, I do not know if the layer of low-level, device firmware, does not remap the blocks - ie for any access in software, yes, the data is "over-written" - but it may be that physically are still there - on SSD disks, for sure this happens)
I believe that as to over-write the files recursively, the other answers here already account for - so I won’t add yet another example of how to do.
Our thanks for this text full of knowledge. then it would be better if I use this way to record the data I used and yes just encrypt the file?
– Guilherme Costa
Encrypting the files is of no use in this context: the encrypted data will be written in a different position from the disk, and the original content will be there for anyone accessing the device directly. Direct HD encryption, yes, is something that all operating systems today allow, and without typing the correct password when turning on the computer, there is no way to read.
– jsbueno
Already, to make it difficult to access - without going to the point of over-writing the data on the physical layer of the disk, write a file of the same name in the same folder, and then delete it, is enough: with this someone just with a tool to look at the filesystem metadata to "unscrew" a file, you’ll arrive in the wrong position. But you should also erase the operating system caches, and take care that mechanisms like Mac OS "time machinne" do not have copies of previous versions of the file.
– jsbueno
I understood. And in the case of Linux, deleting the caches...?
– Guilherme Costa