Making room on a MBP and then a clean up?

[Peter Franks]

Snow Leopard 10.6.8 - 2.3 GHz i5 - Mem 4GB


We all know that when you delete stuff it doesn't really go, so how do you clean up so the machine runs quicker and smoother after you've deleted stuff.

I deleted 175GB off of my 350GB MBP and certainly wasn't going to do a 'secure delete' which I assume would've deleted it properly, as that would've taken about a week.

So what do you guys and gals do to delete space. I'm not going to get full speed and smoothness just by emptying the trash, regardless of how much was in there, as I say, because we know it's still on here somewhere.

I know you don't trust the apps that promise 'clean up', but is there anything you do within the MBP itself to do this? I'm talking machine actual, not deleting internet history, obviously. I hear of running scripts, but does it actually do this and when would it, I don't leave the MBP on, and would that actually clean up what I've discussed anyway?

 

[maflynn]

We all know that when you delete stuff it doesn't really go

Huh?? Why wouldn't deleted stuff not go

I deleted 175GB off of my 350GB MBP and certainly wasn't going to do a 'secure delete' which I assume would've deleted it properly, as that would've taken about a week.

Unless you're dealing with NSA data, or credit cards secure delete is unnecessary and if you have an SSD, its a sure way to incur unneeded write cycles.

So what do you guys and gals do to delete space.

step 1. Drag file/folder to trash
step 2. Empty trash
step 3. Goto step 1 for different folders/files as needed.

I know you don't trust the apps that promise 'clean up', but is there anything you do within the MBP itself to do this?

They're not needed and you can remove the cruft yourself by searching. Leaving them on the disk does not in any way impact performance however. It just consumes space.

To put it another way, deleting files and folders really has no impact on performance.

 

[Peter Franks]

Thanks Mike, I was just led to believe that if you don't overwrite or whatever it's all still there, and that's how people retrieve deleted files/folders? There's nothing sensitive there I just wanted space on machine.

My iDVD wouldn't work when I only had 17 or so GB left on here so it must slow down or affect performance somehow? It did all the processing/multiplexing but when it came to burning disc it told me I had to delete stuff, so assumed it does affect somewhere or other?

 

[maflynn]

Thanks Mike, I was just led to believe that if you don't overwrite or whatever it's all still there, and that's how people retrieve deleted files/folders? There's nothing sensitive there I just wanted space on machine.

I think you're misunderstanding the mechanics of disk storage.

For hard drives (not SSDs), when you delete a file, you are deleting the reference to the file, that is the address to the location of the data. The data is still present until you over-write it. With a secure delete, the contents are overwritten multiple times, but even so with forensic equipment people can still read the latent magnetic singles that once was the data.

For SSDs its a matter of just emptying the contents, i.e., flipping the bits of the memory, so undeleting is generally not feasible in SSD AFAIK

 

[Peter Franks]

So the programmes that promise all those secure deleting multiple times don't actually clean up the machine any more than you can on there already. Nothing more to do...?
Out of interest, when does it disappear, how much new material added to HD does it take to go over what you've deleted, does anyone know?

 

[maflynn]

So the programmes that promise all those secure deleting multiple times don't actually clean up the machine any more than you can on there already. Nothing more to do...?

Correct, they just eliminate the data in a way that makes it harder if not impossible for someone to retrieve the data later on.

Out of interest, when does it disappear, how much new material added to HD does it take to go over what you've deleted, does anyone know?

The general logic is such that it tries not to go over recently deleted files just in case you may want to "undelete" them. There's really no way to determine when it actually occurs. The rule of thumb is to stop using the hard drive if you deleted something that is critical and you absolutely need to recover it.

 

[Peter Franks]

thanks for your help! much appreciated

 

[Fishrrman]

[[ We all know that when you delete stuff it doesn't really go….]]

When you put items into the trash, they remain there until you empty the trash.

When you choose to "empty" the trash, the items are marked in the directory as deleted and the space is free to be re-used. The actual data (out on the sectors of the drive) remains "in place" until it's over-written by new data.

When you choose to "secure empty" the trash, the entries in the directory are deleted AND the sectors on the drive (where the data exists) are immediately over-written with "ones" and "zeros". Thus, the data itself is "gone for good".

 

[Peter Franks]

thanks, but either method leaves the same amount of space left on HD, if you know what I mean? Even If it says 167GB available, whether it's done by secure or not. That's what always confused me, the fact the data is still there but gets over written, and yet the space is free... !

 

[Dark Dragoon]

thanks, but either method leaves the same amount of space left on HD, if you know what I mean? Even If it says 167GB available, whether it's done by secure or not. That's what always confused me, the fact the data is still there but gets over written, and yet the space is free... !

NORMAL DELETE

Say you start of with a drive that can store 30 bits of data, you have two files the first from position 1 to 10 and the second from position 11 to 20.

Catalogue
- File 1 (1-10) = [0110110110]
- File 2 (11-20) = [0100011110]
- Free Space (21-30)

Actual contents of the disk
[011011011001000111100000000000]

Next we delete File 2 normally (not a secure erase), by removing its entry from the catalogue, the free space is then adjusted accordingly.

Catalogue
- File 1 (1-10) = [0110110110]
- Free Space (11-30)

Actual contents of the disk
[011011011001000111100000000000]

At this point we have 20 bits of free space, bits 11 to 30 are available to have data written to them.
It doesn't matter what those 20 bits of free space contain, all thats important is that according to the catalogue the bits are free.

However if someone wanted to look at the disk they could get the data for File 2 back, unless data is written over the top by another file.


SECURE DELETE

Lets start again with the same setup as last time with a drive that can store 30 bits of data, and two files the first from position 1 to 10 and the second from position 11 to 20.

Catalogue
- File 1 (1-10) = [0110110110]
- File 2 (11-20) = [0100011110]
- Free Space (21-30)

Actual contents of the disk
[011011011001000111100000000000]

Next we secure delete File 2 by writing 1's where the file once was. Once that is done we remove its entry from the catalogue, the free space is then adjusted accordingly. We could write 0's (which would be more normal), or it could be some other pattern such as 010101 or even random data. It doesn't matter. I chose 1's as it illustrates the point better.

Catalogue
- File 1 (1-10) = [0110110110]
- Free Space (11-30)

Actual contents of the disk
[011011011011111111110000000000]

The end result is the file catalogue is identical after both a normal delete and a secure delete. As far as the computer is concerned the amount of free space is the same, as the actual contents of the drive doesn't affect the space available.
The only difference is now someone can't come along and look at the part of the drive where File 2 used to exist and get its data back.

Additionally when it comes to writing new data, it doesn't matter what old data was at the location previously.

 

[Weaselboy]

thanks, but either method leaves the same amount of space left on HD, if you know what I mean? Even If it says 167GB available, whether it's done by secure or not. That's what always confused me, the fact the data is still there but gets over written, and yet the space is free... !

I suspect you have Time Machine turned on. What happens is when you delete a file it is not really deleted, but it is placed in a hidden local backups area in case you need to restore the file and you are away from your Time Machine backup disk. You don't need to worry about this though, once the space fills 80% of your disk the OS will start to shrink the local backups area.

You can zero out the local backups space by turning Time Machine off then back on.

You can test this. Run the command below in Terminal and it will show how much space is currently being used by local backups. Turn Time Machine off then back on and run the command again and it will show close to zero space used. Now delete a large file of some sort, then run the command a third time and you will see the local backups folder has grown by the size of the file you deleted.

sudo du -hs /.MobileBackups

 

[Dark Dragoon]

I suspect you have Time Machine turned on. What happens is when you delete a file it is not really deleted, but it is placed in a hidden local backups area in case you need to restore the file and you are away from your Time Machine backup disk. You don't need to worry about this though, once the space fills 80% of your disk the OS will start to shrink the local backups area.

I was wondering this too, however the op says they are running 10.6.8 Snow Leopard and this feature only appeared in 10.7 Lion and newer.

 

[Weaselboy]

I was wondering this too, however the op says they are running 10.6.8 Snow Leopard and this feature only appeared in 10.7 Lion and newer.

Ah... thanks I missed this and am an idiot.

 

[Peter Franks]

Thanks guys, It's that getting my brain to register the fact that 'I've cleared all that space, and it's still on here, so how is the space reduced if it's still on there', if you know what I mean.....

Thanks for your time to explain. Much appreciated