No, I restored the files to a different parition and selected "unallocated space only" every time.

Ok, I ran photorec once again without deleting the large file (and filling up the previously reserved disk space) and it discovered only a few text files which were possibly created and deleted since dd stopped. Interesting, though, is the fact, that after deleting the large file, some files were recovered again (not nearly as much as recovered before). Although mostly small text files were spotted, this shouldn't happen, should it? Can photorec restore overwritten bits sometimes? Maybe running dd if=/dev/zero of=largefile some more times will do the trick? I'll try it out.

Don't wait forever for the hexdump command to finish if it doesn't show anything other than those lines for a while it's fine

An inode always refers to somewhere on the same partition (strictly, its multiple block pointers refer to somewhere on the same partition). You can't have file systems covering multiple partitions.

If you want the exact block address within the partition, I guess that is what photorec is telling you: but you have no guarantee that another process won't write another file there after you have deleted it, because the OS thinks the space is free.

Now I don't understand. Are the files fully deleted or simply moved to another partition? If the files exist elsewhere on the drive, maybe photorec is scanning that as well?

Definitely not! If they were recovered, they were not originally overwritten.

1 members found this post helpful.

The files were deleted using rm. After photorec discovered such a deleted file, it copies the contents to a new file on another partition (I restore files form sda3 and store the recovered files on sdb1)

Then it is very strange that photorec recovered sooo much files, because I'm definitely sure that every unallocated bit was zeroed. And it is impossible that every file was created and deleted after if removed the large file.

One thing has occurred to me: if a block containing some of a deleted text file is then allocated to another file, which doesn't write over all of it, the text data won't be cleaned by this technique. To illustrate what I mean ...

Time 1: sensitive.txt is a 4KB file taking one 4KB block at location 1000000
Time 2: sensitive.txt is deleted. That disk block is marked free but still contains the text data
Time 3: arbitrary.tmp, a 1 byte file, is allocated to the same location. That disk block is not free, and now contains 1 (or 2 including a NUL?) bytes of the new file but still contains 4094 bytes of your text
Time 4: you run the dd largefile command. Block 1000000 isn't touched because it's not free.
Time 5: arbitrary.tmp is freed but your text data is still on the disk.
Time 6: you delete 'largefile' (or not, makes no difference)
Time 7: you run photorec and it finds that text data, with a couple of garbage characters at the front.

shred (run before deleting the file) I think would address this by overwriting the bytes in the disk block before deleting the file.


... And another thing: ext4 is a journalling file system. I have no idea what the implication of this is (how much written data is copied where), but man shred warns that it may not work on journalling file systems.

1 members found this post helpful.

Hey thank you, your last post seems logical. But for the main problem being solved by disabling reserved blocks, I am pleased now It just seemed strange that my first approach didn't work.

So once again thank you for your help and I'll use the button

The only real solution to safe deletion is to put your drive into an industrial shredder.