How to find the block of a deleted file? how to erase or over written a special block?
Depends on the drive type SSDs use different strategies from rotating rust drives.
Also what do you mean by special blocks???
I’m really sorry, My mean is given block or specific block 
Can Moderator changes the wrong words?
I want to write files on the block of deleted file to make it complete disappeared from my disk, I don’t want to wipe all the freespace.
Am I correct that you mean you had a file on a file system (you never told us what type of file system), you deleted the file. Thus the blocks earlier allocated to the files, that can be spread all over the file system, became free (and at least part of them can now be used by new created or extended other files) and the inode also became a free one (and thus can be used in the mean time for a new file).
Now places withing files using Unix/Linux are addressed in bytes. These bytes are indeed grouped in blocks on a low level and written as such to the disk, but remind that on the physical disk the blocks size can be different again. Even assuming that you calculated some byte addresses into a block address (either logical and/or physical), it will be very difficult to identify this block on the volume where the file system is stored on, because of all the lost pointers as indicated above.
Best thing to do is of course first stopping with any write actions to the file system, then by trying to recover the file (which is not easy in Linux, but there are some tools with which one can try this). When you recovered the file, I assume it will be easy enough to erase all of it’s contents including the part that you want to overwrite.
In the future, you should use a utility that will “wipe” a file’s content on disk at the time you want to delete it.
Dont run “rm”, then try to find the file’s low-level disk content. Just one small mistake doing that can corrupt the disk.
.
The utility named “shred” is a possible tool. There are a few other options.
BTW:
You didn’t mention the filesystem type you’re using and if that filesystem is encrypted.
That is a good option for the future.
@ysat …
If you are that worried about the deleted file, I can think of a couple options.
Copy a very large binary file (like an image) to the sub-directory where the deleted file was. I would find a binary file that is about 10 times larger than the deleted file. Doing this will most likely overwrite the deleted file’s content at the disk level. Maybe copy a few large binary files. Afterwards, you can wipe those.
The second option will work, IF you have a separate /home partition.
- Backup the /home using rsync (or whatever you use).
- Now reformat (NOT a quick format) the partition with whatever filesystem is used
- Finally, restore /home content with the backup.
Just a general comment here.
The way that I deal with this problem, is by encrypting the partition. That way, when I delete a file, I don’t worry about what is left on the disk, because it is all encrypted anyway.
1 Like
Copy a very large binary file (like an image) to sub-directory is time-wasting, I don’t want to do this to my USB thumb, which is very slow and very big, the BleachBit shows that 10 hours needed to finish the wipe action, for erasing 2M bit files.
Maybe you better explain now what you want. You are now talking about a USB connected mass-storage device, that is new. Remind that we can not read your brain. You can above different advises that point to different interpretations of what your goal is.
I see this as an example of How To Ask Questions The Smart Way
Maybe what I want to do is to find the position of deleted file ( testdisk, it can recover the deleted files, so it knows the position of the files) on USB thumb drive, and write random data on it, so I don’t need to wipe the entire partition.
Of course you can overwrite an existing file easy enough. Thus when you can “un-delete” it, you then can overwrite it and after that delete it for good.
When you can not un-delete it, I am afraid you are too late and have to overwrite the complete file system.
1 Like
It is not an existing file, it has been deleted and couldn’t see from the file manager.
The deleted file can be recovered, but I want it gone forever.
Well then, un-delete the file, then wipe it - those two steps shouldn’t take more than 5 minutes. This thread is now five days - it’s unclear what the hesitation is.
1 Like
When restoring the deleted file, how to sure it is in the original place? If it is in the original place, then I can shred it, if not, I can’t shred the original place.
No, it does not. It can only guess. When a file is deleted, the information about its location is lost. All you have is the first cluster location and the file size. Even if enough contiguous clusters are free, there is no way to be sure these clusters belonged to the deleted file or to know whether this file was fragmented.
If shredding the content of this file is so important to you, the only way to be sure is to shred the whole device.
1 Like
We are not talking about “restoring” (which means copying it from a backup).
We are talking about “un-delete”, or as you called it earlier “recover”.
So maybe a bit of misunderstanding. There are some tools that allow “recover”/“un-delete” of a file when you use them asap after the unwanted delete (that is before other files are written). But I assume they are seldom successful. Nevertheless, we interpreted your saying of “I can recover” that you could do it.
Indeed “restoring” from elsewhere will put it on a different blocks in the file system.
As we have tried to explain from the beginning of this thread: you deleted/removed the file and thus destroyed all information about where was. You are simply too late to overwrite (anything in) the file.
You should have shred the file before you deleted it. And it is too late now.
1 Like
Shredding on SSD does not guarantee that the file content was overwritten either. Which is why ATA/SCSI/NVMe have commands to actually erase the content of the underlying flash (SECURITY ERASE/SANITIZE). You probably can achieve the same by overwriting the whole media at least twice (I have seen SSD devices that internally reserved half of the physical capacity).
Yes, what SSD device do internally seems to be rather unpredictable (maybe predictable when one particular brand and type is taken into consideration).
From man shred:
CAUTION: shred assumes the file system and hardware overwrite data in place. Although this is common, many platforms operate otherwise. Also, backups and mirrors may contain unremovable copies that will let a shredded file be recovered later. See the GNU coreutils manual for details.
And I assume that that is very, very cautious and generalized remark that does not take modern (SSD) devices fully into account. Searching for “shredding file contents” on the Internet will probably reveal many insight docs. Including movies about destroying disks with fire or other violence.
How to find the block of a deleted file?
For existent files is “hdparm -fibmap” your friend: