When running Recuva deleted file names are displayed.Secure deleting files on SSD is not recommended (TRIM should take care of it?)

I just ran Recuva on an SSD and it showed a lot of files and foldernames, even though TRIM is active.

Up front, I don't know whether it is workable or not, but I just -wondered- ...

Say that once you are deleting a file (for the sake of argument, let's call it 'safe delete')So, let's say you are 'safe deleting' a file, using 'some kind of special instruction/or tool'it would then go as follows:the file will be renamed to some random name e.g. l2LCAnnRpIMkUTmpKf0q.tst then it will be moved to a scratch folder with some random name as well, for instance, it is moved to D:\lCQgD45dJSEX1DFLkW8Ethen it will be deleted there.Recuva will show weird paths and weird name, making it at least difficult to guess what it is about.

Right now, within Recuva, one can often guess based on path names.

Again, it is just an idea!

There may be tools that secure delete files on SSD, but they do not clear the MFT records.

Yes, the SSD software (Samsung Magician) also provides secure erase.That covers the entire drive and will probably run for a century.

Other software, like Eraser, can securely delete files only, which in most cases is enough.In most cases there is no need to secure erase each and every file, but only specific ones, or specific folders.

However, in such cases, after securely deleting files and after running recovery software the file names / folder names are displayed.Even though files can not be recovered, names show what they were about.

That's the background of my idea.

So, as securely deleting -files- on SSD is not possible, at least not that I know of, then the only thing left is to 'hide' them as best as possibleusing random names and random 'scratch' folder.So: - randomize file name- create a scratch folder with a random name- move file to that folder- delete that folder

I find your logic a little flawed with this procedure to supposedly disguise what folder a file originally came from in the event anyone tries to recover deleted files.

The original folder still exists, pretty much any attempt to disguise where any file came from is pointless since if anyone is interested enough to care about the name of that folder they should rightly assume that any and possibly all files came from that folder regardless of their name or where they now appear on the drive.

Given 1, it's enough to securely delete the file in the original folder without screwing around wasting write cycles on the SSD.

A clean SSD with just one folder and two files, Recuva set for DeepScan, show everything:

Two files on an SSD:Rename folder and files before deleting

Two files deleted, top one using DOpus secure delete, (since you were asking over there), the bottom using Moo0 FileShredder:Rename folder and files before deleting

After Moo0 Anti-Recovery (with just the MFT options selected, takes a couple of seconds):Rename folder and files before deleting

And just for an added extra, single file deleted with Microsoft's own SDelete:Rename folder and files before deleting

You'll note the file name has partially become the original folder name, you could easily write a PoSh script that renames the folder, runs SDelete on the file(s), and then changes the folder name back.

Is this a SSD you are using in this test? Fileshreders like Eraser, BCWipe, etc. work well on conventional HDD'sbut they say they don't work well on a SSD.On a SSD 'TRIM' should do the work.When you run Recuva on your SSD (if you have one), then you will see that a lot of data is revealed.

Opus itself does have a secure delete of files.Recuva will then show a very long file name consisting of random characters, but it also shows the original folder name.

Ideally it would look like this screenshot, all with Z...ZZ names and folders

Sorry.... overlooked it multiple times, too much focused on on the thought that using file shredders on SSD should be avoided.Hence assumed I was looking at HDD screenshots. Sorry again.Will check out reviews on file shredders.Thanks again for taking the time.

That is going to take a fair bit more time than just doing specific files and clearing the MFT plus it puts unneeded write cycles on the SSD.

ie. If a block is wiped on the first running of CCleaner and there has been no change to it, (no data written to that block), when you next run CCleaner it will wipe an already wiped block.

It's not designed to keep track of block writes and only wipe those that have been used between runs, you're needlessly shortening the life of your SSD, (considering it will do 1 -> 3 writes on each and every block that is marked as free).

... too much focused on on the thought that using file shredders on SSD should be avoided.