Belle2018pablo wrote:
Does the file or data not just get moved to unallocated space until overwritten? Or is it truly erased? Any more information thanks
Fundamental to flash storage technology, re-using flash storage requires that the storage be erased before it can be re-used and rewritten, and that erasure process is comparatively slow with flash. With flash, reads are fast, writes are fast, but erasure is both necessary and unfortunately comparatively slow. That speed differential means that the erasure operation preferably happens as soon as is feasible after the storage has been released from use. That sequencing makes the subsequent re-use of the storage much faster, as you’re not waiting for the erasure to happen before the rewrite and re-use; before the write. That also means there isn’t any data to recover. Not once the storage device has finished processing its pending-work (erasure) queue.
Moving the storage around at deletion would involve additional effort for something being deleted, and being permanently deleted, and that move would necessarily also use free storage. What I suspect you’re referring to here however is the process known as wear leveling, which doesn’t move existing storage contents around, it moves the storage used for new writes around.
Wear leveling exists as all storage has a useable life (a limit on the total numbers of reads or writes permissible), and with flash particularly. Rather than rewriting the same (physical) storage each time, each rewrite picks different (virtual) storage from the available storage pool, and re-maps it. An app writing to, say, (virtual) sector 1 in the storage pool each time actually writes to a different (physical) sector currently mapped as (virtual) sector 1. This remapping or wear leveling process avoids exceeding the total rewriting capabilities of a particular storage sector. Most (all?) modern hard disks have something similar to this mechanism, with sectors being remapped when storage errors occur; a so-called bad or defective sector list is maintained, and a spare “good” sector replaces (remaps) a bad sector.
And yes, flash storage also remaps sectors with detected errors. Same as modern hard disk drives.
Most devices are also over-provisioned; have more internal storage than was advertised, or was reported to the operating system. This is also why cheaper flash storage has fewer of these “spare” sectors—so-called over-provisioning—and why running flash storage near or at capacity can potentially also have a detrimental effect on longevity; why storage can sometimes wear more quickly, and why running near or at full is Bad.
The TRIM command mentioned above is one of various ways an operating system can inform the underlying storage of a status change for a particular part of storage. TRIM triggers the erase of the sector, and (indirectly) also the remapping of storage for wear leveling. Some configurations will use a sector-of-zeros write to trigger this same erase and remapping process, for instance. TRIM places the storage sector in a pending-erasure queue.
The traditional concept of data remanence or of “disk scavenging” is from the era of hard disks, as those don’t need to erase before the sector csn be re-used and rewritten, though operating systems can be implemented and configured to erase storage at discontinuance of usage (at deallocation). (This is also why some system configurations can respond to writes of zeros as a TRIM command, too.)
Now can you capture existing data in that pending-erasure queue? Maybe. If you can capture the remaining data immediately after the deletion, and before the device finishes processing its queue of storage sectors pending erasure; its TRIM queue. But while flash storage erasures are slow in terms of flash storage performance generally, they’re still pretty speedy in human terms, and devices are seldom powered down immediately after the deletion.
Which is a lot of words for this: permanently-deleted files are permanently deleted.
