cgsecurity.org

I used these commands on an SSD with an ext4 filesystem to write zeros to the free space on the drive.
cat /dev/zero > remove.file
sync
rm remove.file

after removing the file, photorec still finds plenty of deleted data. trying to figure why/how photorec is doing that?

Photorec simply sees everything.

What is "remove.file"?

recuperation wrote: ↑26 Oct 2023, 19:55 Photorec simply sees everything.

What is "remove.file"?

remove.file is just a text file name i chose to send /dev/zero to. then i delete the file and in theory should not be any data left to recover.

If Photorec understands the inner workings of the file system you have the option to have Photorec either search the whole space or the unused one. The data you found may originate from used space. If Photorec does not understand the file system used it cannot distinguish between used space and unused one.

There is no guarantee for your theory to be working.

@callmejoe

Two remarks:

It may well be that your dd command did not fill up all empty space.
I assume that the dd command was run as a regular user. In that case linux filesystems reserve some free space for root.
This is to avoid that a user fully fills up the filesystem leaving no room for system applications to do their thing (e.g. write to a log file).
See e.g. here for some info: https://unix.stackexchange.com/question ... system-why

Second thing is that, depending on your operating system data is not yet really deleted.
E.g. under ubunto if you delete a file from the file manager it ends up in Trash.
So the file still exists but in .local/share/Trash
This could also be why you still see files.

callmejoe wrote: ↑25 Oct 2023, 19:45 I used these commands on an SSD with an ext4 filesystem to write zeros to the free space on the drive.
cat /dev/zero > remove.file
sync
rm remove.file

after removing the file, photorec still finds plenty of deleted data. trying to figure why/how photorec is doing that?

I'm not completely sure that, on Linux systems, the 'sync' call, especially when issued from a normal (non-root) user will ensure the immediate flush of the VFS. Perhaps you could try to umount the drive after the write and then remount it before Photorec it.
Furthermore, there could be somewhere a sparse-file optimization handling active.

For an in-deep discussion of a very similar case: https://www.baeldung.com/linux/wipe-free-space

gianfrus wrote: ↑07 Jan 2024, 17:44
For an in-deep discussion of a very similar case: https://www.baeldung.com/linux/wipe-free-space

thanks for that link. good validation of the various wiping techniques

recuperation wrote: ↑01 Nov 2023, 18:31 If Photorec understands the inner workings of the file system you have the option to have Photorec either search the whole space or the unused one. The data you found may originate from used space. If Photorec does not understand the file system used it cannot distinguish between used space and unused one.

There is no guarantee for your theory to be working.

I just wiped one of my old spinning HDDs by writing zeros to the entire disk. im using photrec now to see if it finds anything (it's still running, probably will take 2 hours to complete), but i am confident it wont recover anything.

and now 3 months after my original post, your post finally clicked with me. the files photorec found could have certainly been from the used space. i dont remember if I set the options for photorec to just search in the unused space or not. i'll have to try again.

i am not getting this page to select whole partition or unallocated space.

photorec version 7
using ext4 filesystem

https://imgur.com/a/CLADjAY

Sometimes I feel like I should bang my head against the wall until it breaks.