Q: Terminal Shell Task/Coding Issue
-
Nov 14, 2015 5:53 PMby hiccup ,How can I use the second code after the first code, when the first code deletes and removes file? is there a way to execute both codes at once? I have a feeling that Apples Finder coded executed more than one task to deletion, hence the time difference.
/usr/bin/time -pl srm -m
followed by
rm -rP /path/to/file-or-folder
Overwrite the contents before the deletion (from the terminal);
rm -rP /path/to/file-or-folder
Where r is to recurse over the folders and P will overwrite their contents
OR should I do this:
/usr/bin/time -pl srm -m
diskutil secureErase freespace 2 /Volumes/DRIVENAME
I really wonder just what Apple used! its sad they've started crippling Disk Utilities (they first removed 35pass in Mavericks - no one seemed to notice, now its gone completely) and Finder, even those the are literally millions still using Hard drives. When SSD drives become as cheap as a 2T HD I'll adopt.
-
Nov 14, 2015 6:38 PMby BobHarris,How can I use the second code after the first code, when the first code deletes and removes file?
If you are testing, then you take a file
cp test.file file.to.be.deleted
/usr/bin/time -pl srm -m file.to.be.delete
cp test.file file.to.be.deleted
/usr/bin/time rm -rP file.to.be.deleted
Wash/Rinse/Repeat...
they first removed 35pass in Mavericks
On modern disks with very narrow tracks and very high bits densities, there is very little residual magnetism after just 3 passes. 35 passes is not really needed any more to make recovering most of your data very expensive, if at all.
Actually 1 pass of zeros is good enough unless you expect someone with an excessive amount of money to spend trying to recover your data.
But if someone has money to spend, then as has been mentioned before, all the secure erase operations leak data that may still expose some of your data. And SSDs do not do what you think they are doing and secure erase just shortens the life of the SSD.
Leaks:
- Bad sector replacement (the bad sector may still have readable data)
- apps used to read/edit your data may use temp files or caches that do not get securely erased.
- apps commonly write updated files to a new file, then rename the new file to the original name, where the file system will just delete the original file, in an unsecure manor.
- If OS X decides it wants to defragment your file, it will move it to new storage and free the previous storage in an unsecure manor
- If you use a Fusion drive, a file will be first written to the SSD side of the Fusion drive, and then later migrated to the rotating hard disk. The original SSD storage will be freed in an unsecured manor
- And if you have an SSD, secure erase does not over write the original sectors, but newly allocated sectors that never had your data in them, and the original sectors given over the SSD pool of sectors to be eventually reused.
There are so many ways your sensitive data can be left sitting on your storage in an unsecured state.
If you are truly worried about your data, then you will stop playing with secure erase, and use FileVault. -
Nov 15, 2015 8:44 AMby MrHoffman,hiccup wrote:
...its still suspiciously fast...
Download and review and build and run the srm tool yourself.
File and full volume encryption are — as Bob Harris correctly states — the current solution to these cases.
