Wolf K wrote:
On 2018-05-09 11:34, NY wrote:
"David E. Ross" wrote in message
news
Two actions are really meaningless for SSDs.

The other action that is meaningless is erasing files. The writing
needed to erase a file might fail to over-write that file. While the
pointer to the file might be erased, the file contents remain untouched.
Only a total erasure of the entire device could have any meaning.
Details about this are at http://eraser.heidi.ie/.

As with any storage device (whether SSD or HDD), when you erase or
overwrite
a file, you are not deleting the contents at that time; instead you are
returning the "sectors" (to use HDD terminology) to a pool which can
be used
for a new/updated file at some time in the future.

It still makes sense to erase files that are no longer needed, so as
to free
up space and for general housekeeping. But unless you overwrite all the
unused sectors that are not allocated to files/folders (or erase the
whole
device, as you say), then there is the possibility that someone may be
able
to undelete the file - that applies to HDD as much as to SSD.


So I'd say that defragging an SSD doesn't make sense, but erasing a
file makes as much or as little sense for both HDD and SSD.


Semantics alert:

"Erase" = "Overwrite data"
"Delete" = "Mark filename as Deleted, and mark sectors/clusters as
Available"

Best,

You can do both if you want.

You can do a defragmenter run first. Followed by a run of
Sysinternals SDELETE with the -z option to zero white space.
Then, there will be nothing for Recuva to find, and the file
system will be in a "maximally recoverable" state in the
event the partition header got erased or something. Scavenger
file recovery programs work best, if the files were
defragmented before the accident happened.

I don't think anyone has that much of a disk fetish though.

Paul