Erase Free Disk Space Mac
2021年10月28日Download here: http://gg.gg/wcn0j
*Erase Free Disk Space Macbook Air
*Mac Disk Utility Erase Free Space Greyed Out
*Erase Free Space Windows
*online, free Disk Space
*The bigger the files you can delete, the more space you can free up—so let’s go hunting. Click the Apple menu in the top-left corner of the menu bar and choose About This Mac. If that overview.
*So, first, ensure that the system is, in fact, running out of free space. There are two methods to check available space on a hard drive: 1. Access the Apple menu and select About this Mac. Choose the Storage tab. More detailed information can be found within the Disk Utility feature, which is located in the Applications folder under.
*To free up disk space, it’s helpful to know exactly what is using disk space on your Mac. A hard disk analysis tool like Disk Inventory X will scan your Mac’s hard disk and display which folders and files are using up the most space. You can then delete these space hogs to free up space.
For privacy and security reasons, you can set CCleaner for Mac to wipe the free areas of your hard disk so that deleted files can never be recovered. Note: Wiping free space can take several hours. To wipe your drive using Erase Freespace: Click Tools, and then click Erase Free Space. Select the volume whose free space you want to erase.Erase Free Disk Space Macbook AirErase free disk space from the command line | 18 comments | Create New AccountClick here to return to the ’Erase free disk space from the command line’ hint The following comments are owned by whoever posted them. This site is not responsible for what they say.
Wouldn’t you be much better off using /dev/random instead?
’Wouldn’t you be much better off using /dev/random instead?’ No, that would actually be terrible. First of all, you shouldn’t fill the boot disk of a running machine because it will cause problems, so the hint is a bad idea anyway. However, if you are anxious to do bad stuff like fill your root drive, then you definitely shouldn’t do it from /dev/random, because /dev/random requires vastly more CPU power to generate data for than /dev/zero does. If would take few hours to fill a drive from /dev/zero, but it could take a few weeks to fill it from /dev/random. Also, I don’t know if Mac OS X does this, but Linux will sometimes block on reads from /dev/random while it waits for more genuinely random input from the outside world (say mouse movements, or network traffic rates or some such). (This used to cause ’depleted entropy pool’ problems for ssl and ssh on linux. Sorry for the ’in my day’ storry, but I remember when I used to use linux to generate SSH keys and I would have to wiggle my mouse around a lot in order to generate ssh keys in a reasonable amount of time. :-)
Yes, I remember when I setup a FreeBSD server ~5 years ago, I got the standard generating key message you would normally get, then something odd telling me to ’wiggle my mouse or hit keys on the keyboard’. You feel like an idiot standing at a console in the server room, ’wiggling the mouse’, and banging on the keyboard, with other admins* walking around asking you if you have gone insane. Its funny now, not so much back then. * They were Windows admins, I was the *nix admin at that time.
Firstly one does not run this as root. run this as a normal user. The system reserves some space for the root user, and this way you will not run out of disk space for critical system. (At least I know this to be true for reiser, ext3 and ext2 filesystems on Linux. Secondly, anyone paranoid enough to want to do it should never use /dev/zero (Not even when doing it multiple times) since you can still get the data using forensic techniques. Even if you do this multiple times... some drives with advances caching may not even do the successive writes on a very low level (even with only a small sized disk-cache). Lastly, yes, /dev/random is more cpu intensive... as for a lot more? No it does not: I did: (cat /dev/zero > zero &) ; (cat /dev/random > random &) ; sleep 20 ; killall cat ; ls -l zero random And it showed: joseki:~ marius$ ls -la random zero -rw-r--r-- 1 marius staff 222302208 Apr 24 12:27 random -rw-r--r-- 1 marius staff 666898432 Apr 24 12:27 zero So, yes, I would suggest using random... a good system-wide anti-entropic engine should be pretty efficient.I would think that this could be equally useful using /dev/random or /dev/zero. ramdom would help obscure old data from disk searches. zero would allow for the raw partition to be more easily compressed.
As UNIX SysAdmin, I don’t think this makes any sense at all. First, filling up your drive is a very bad idea, as Rob points out. Many services will stop functioning or exhibit odd behavior. Secondly, I’m not quite sure what you’re trying to do here? Make sure any unused sectors are zero’d out? I’m guessing you’re using secure delete already anyways. This just doesn’t make any sense. Do you work for the NSA? Didn’t think so. You don’t need to ’zero’ your unused disk space. P.S. - This ’35 pass delete’ stuff is B.S. The only way to recover data from a HD after 3 passes is with a team of people and highly specialized hardware. Sorry everybody, but my guess is that your data is not that important. Save your hard drive life and stop using 35-pass deletes. If you have sensitive data, encrypt it using a strong passphrase and you’ll be much better off.---Nem W. Schlecht http://geekmuse.net/
Not only is this not a good idea, it doesn’t entirely work as advertised. Realize that changes to files are often not written to disk immediately. Instead, they are held in memory (cached) and queued for writing to disk. So, when your cat command dies due to insufficient space, it’s likely that some of the writes have not completed. When the file is removed, those writes can be deleted from the queue of pending writes. Consequently, some of the disk blocks will never be overwritten. Also, many filesystems limit the amount of disk that a regular user (i.e. not root) can write to. For instance, UFS reserves 10% of a filesystem (by default, can be set with tunefs minfree option) for root. This would mean that the above command would fail after writing to 90% of the disk, not 100% (leaving 10% unwritten). Unfortunately, I’m not familiar with the implementation of HFS+, so I can’t comment on whether it has similar behavior.
’Do you work for the NSA? Didn’t think so. You don’t need to ’zero’ your unused disk space.’ I’m guessing you know the things I’m about to say already and just didn’t think about them when you wrote this, but using secure erase means that Finder is configured to do secure erase when it empties the trash. It has no impact on, say Quicken’s temporary files in /tmp . File in /tmp are also outside of the user’s FileVault (assuming this person is using FileVault). There have also been multiple cases where people have suffered identity theft after their financial information was lifted from old drives despite the fact that it had already been (insecurely) deleted on the old drive. With that said, FileVault, secure erase, and encrypted VM will cover the vast majority of people’s needs. In fact, simple lack of familiarity with HFS+ on the part of thieves will cover a lot. Nonetheless, there are legitimate cases for a non-FBI-employee to want to erase the blank space on a root drive.
some of us do. given, this isn’t the best way to go about it, it would help prevent some data recovery. if you want to use this method, i would recommend booting into single use mode first. (cmd-opt-s) diskutil is the correct way to do this. ------ Disk Utility Tool Usage: diskutil secureErase [freespace] level MountPoint|DiskIdentifier|DeviceNode Securely erases a disk or its freespace. Level should be one of the following: 1 - Single-pass randomly erase the disk. 2 - US DoD 7-pass secure erase. 3 - Gutmann algorithm 35-pass secure erase. Ownership of the affected disk is required. Example: diskutil secureErase 2 /dev/disk2 Note: Level 2 or level 3 secure erases can take an extremely long time.
er, diskutil secureErase freespace 1 /dev/xxxSo, if you change the hint to: then the file will magically disappear as soon as the drive fills up. This is slightly safer since it does not fail if RAM fills up to. For example, there are reasons why a rm call might not complete. In a ram-tight situation (if, say, the filesystem cache were to get rather large), then a fork might fail if there’s no room on the swap device for more vm. JP
---Pell Mac Disk Utility Erase Free Space Greyed Out
As robdew pointed out, you can do this with diskutil. A good rule of thumb is that if Disk Utility can do it, diskutil can do it. In fact, Apple is great at letting you do anything (and more!) from the command line - for example, the ’softwareupdate’ command for auto-updates.Erase Free Space Windows
The right method to perform this very action is part of diskutil: diskutil secureErase freespace 1|2|3 /dev/disk#s# (See the man page on diskutil) Band-aids never work right. They always peal off!
But that won’t work unless you have root access, right?Not sure if this applies on MacOSxtended, but ext2/3 reserved 5% of space for the root user. If so the rm method would leave 5% untouched if run without privileges. online, free Disk Space
This command does exactly what Disk Utility does. If your computer crashes during a wipe of the free space, you will find that your hard disk space is reduced. Removing the zeroed file from /tmp (if I remember correctly) will restore the disk space. Try doing it in Disk Utility and watch your disk space shrink. As others have pointed out, some disk space is reserved for root, and therefore the chance of a crash is minute. Thanks, robdew, for pointing out the secureErase option of diskutil. Some how I missed that. It does exactly the same thing.
...if you’re concerned about running the aforementioned ’erase free space’ operation on a ’live’ filesystem, you may want to shut down your system and reboot with your OSX install disc and run Disk Utility from there instead. Or, (in keeping with the spirit of the original hint of using the cmd-line) reboot with your OSX install disc into Single User mode (documented elsewhere) then use the diskutil tip mentioned earlier.Just use the diskutil. Open terminal, type df and hit enter. Get the name of your disk (probably /dev/disk0s2) and type the diskutil command to erase free space which is: diskutil secureErase freespace 1 /dev/disk0s2 That will erase your free space with random numbers. See the list of options below: Level should be one of the following: 0 - Single-pass zeros. 1 - Single-pass random numbers. 2 - US DoD 7-pass secure erase. 3 - Gutmann algorithm 35-pass secure erase. 4 - US DoE 3-pass secure erase.
Download here: http://gg.gg/wcn0j
https://diarynote.indered.space
*Erase Free Disk Space Macbook Air
*Mac Disk Utility Erase Free Space Greyed Out
*Erase Free Space Windows
*online, free Disk Space
*The bigger the files you can delete, the more space you can free up—so let’s go hunting. Click the Apple menu in the top-left corner of the menu bar and choose About This Mac. If that overview.
*So, first, ensure that the system is, in fact, running out of free space. There are two methods to check available space on a hard drive: 1. Access the Apple menu and select About this Mac. Choose the Storage tab. More detailed information can be found within the Disk Utility feature, which is located in the Applications folder under.
*To free up disk space, it’s helpful to know exactly what is using disk space on your Mac. A hard disk analysis tool like Disk Inventory X will scan your Mac’s hard disk and display which folders and files are using up the most space. You can then delete these space hogs to free up space.
For privacy and security reasons, you can set CCleaner for Mac to wipe the free areas of your hard disk so that deleted files can never be recovered. Note: Wiping free space can take several hours. To wipe your drive using Erase Freespace: Click Tools, and then click Erase Free Space. Select the volume whose free space you want to erase.Erase Free Disk Space Macbook AirErase free disk space from the command line | 18 comments | Create New AccountClick here to return to the ’Erase free disk space from the command line’ hint The following comments are owned by whoever posted them. This site is not responsible for what they say.
Wouldn’t you be much better off using /dev/random instead?
’Wouldn’t you be much better off using /dev/random instead?’ No, that would actually be terrible. First of all, you shouldn’t fill the boot disk of a running machine because it will cause problems, so the hint is a bad idea anyway. However, if you are anxious to do bad stuff like fill your root drive, then you definitely shouldn’t do it from /dev/random, because /dev/random requires vastly more CPU power to generate data for than /dev/zero does. If would take few hours to fill a drive from /dev/zero, but it could take a few weeks to fill it from /dev/random. Also, I don’t know if Mac OS X does this, but Linux will sometimes block on reads from /dev/random while it waits for more genuinely random input from the outside world (say mouse movements, or network traffic rates or some such). (This used to cause ’depleted entropy pool’ problems for ssl and ssh on linux. Sorry for the ’in my day’ storry, but I remember when I used to use linux to generate SSH keys and I would have to wiggle my mouse around a lot in order to generate ssh keys in a reasonable amount of time. :-)
Yes, I remember when I setup a FreeBSD server ~5 years ago, I got the standard generating key message you would normally get, then something odd telling me to ’wiggle my mouse or hit keys on the keyboard’. You feel like an idiot standing at a console in the server room, ’wiggling the mouse’, and banging on the keyboard, with other admins* walking around asking you if you have gone insane. Its funny now, not so much back then. * They were Windows admins, I was the *nix admin at that time.
Firstly one does not run this as root. run this as a normal user. The system reserves some space for the root user, and this way you will not run out of disk space for critical system. (At least I know this to be true for reiser, ext3 and ext2 filesystems on Linux. Secondly, anyone paranoid enough to want to do it should never use /dev/zero (Not even when doing it multiple times) since you can still get the data using forensic techniques. Even if you do this multiple times... some drives with advances caching may not even do the successive writes on a very low level (even with only a small sized disk-cache). Lastly, yes, /dev/random is more cpu intensive... as for a lot more? No it does not: I did: (cat /dev/zero > zero &) ; (cat /dev/random > random &) ; sleep 20 ; killall cat ; ls -l zero random And it showed: joseki:~ marius$ ls -la random zero -rw-r--r-- 1 marius staff 222302208 Apr 24 12:27 random -rw-r--r-- 1 marius staff 666898432 Apr 24 12:27 zero So, yes, I would suggest using random... a good system-wide anti-entropic engine should be pretty efficient.I would think that this could be equally useful using /dev/random or /dev/zero. ramdom would help obscure old data from disk searches. zero would allow for the raw partition to be more easily compressed.
As UNIX SysAdmin, I don’t think this makes any sense at all. First, filling up your drive is a very bad idea, as Rob points out. Many services will stop functioning or exhibit odd behavior. Secondly, I’m not quite sure what you’re trying to do here? Make sure any unused sectors are zero’d out? I’m guessing you’re using secure delete already anyways. This just doesn’t make any sense. Do you work for the NSA? Didn’t think so. You don’t need to ’zero’ your unused disk space. P.S. - This ’35 pass delete’ stuff is B.S. The only way to recover data from a HD after 3 passes is with a team of people and highly specialized hardware. Sorry everybody, but my guess is that your data is not that important. Save your hard drive life and stop using 35-pass deletes. If you have sensitive data, encrypt it using a strong passphrase and you’ll be much better off.---Nem W. Schlecht http://geekmuse.net/
Not only is this not a good idea, it doesn’t entirely work as advertised. Realize that changes to files are often not written to disk immediately. Instead, they are held in memory (cached) and queued for writing to disk. So, when your cat command dies due to insufficient space, it’s likely that some of the writes have not completed. When the file is removed, those writes can be deleted from the queue of pending writes. Consequently, some of the disk blocks will never be overwritten. Also, many filesystems limit the amount of disk that a regular user (i.e. not root) can write to. For instance, UFS reserves 10% of a filesystem (by default, can be set with tunefs minfree option) for root. This would mean that the above command would fail after writing to 90% of the disk, not 100% (leaving 10% unwritten). Unfortunately, I’m not familiar with the implementation of HFS+, so I can’t comment on whether it has similar behavior.
’Do you work for the NSA? Didn’t think so. You don’t need to ’zero’ your unused disk space.’ I’m guessing you know the things I’m about to say already and just didn’t think about them when you wrote this, but using secure erase means that Finder is configured to do secure erase when it empties the trash. It has no impact on, say Quicken’s temporary files in /tmp . File in /tmp are also outside of the user’s FileVault (assuming this person is using FileVault). There have also been multiple cases where people have suffered identity theft after their financial information was lifted from old drives despite the fact that it had already been (insecurely) deleted on the old drive. With that said, FileVault, secure erase, and encrypted VM will cover the vast majority of people’s needs. In fact, simple lack of familiarity with HFS+ on the part of thieves will cover a lot. Nonetheless, there are legitimate cases for a non-FBI-employee to want to erase the blank space on a root drive.
some of us do. given, this isn’t the best way to go about it, it would help prevent some data recovery. if you want to use this method, i would recommend booting into single use mode first. (cmd-opt-s) diskutil is the correct way to do this. ------ Disk Utility Tool Usage: diskutil secureErase [freespace] level MountPoint|DiskIdentifier|DeviceNode Securely erases a disk or its freespace. Level should be one of the following: 1 - Single-pass randomly erase the disk. 2 - US DoD 7-pass secure erase. 3 - Gutmann algorithm 35-pass secure erase. Ownership of the affected disk is required. Example: diskutil secureErase 2 /dev/disk2 Note: Level 2 or level 3 secure erases can take an extremely long time.
er, diskutil secureErase freespace 1 /dev/xxxSo, if you change the hint to: then the file will magically disappear as soon as the drive fills up. This is slightly safer since it does not fail if RAM fills up to. For example, there are reasons why a rm call might not complete. In a ram-tight situation (if, say, the filesystem cache were to get rather large), then a fork might fail if there’s no room on the swap device for more vm. JP
---Pell Mac Disk Utility Erase Free Space Greyed Out
As robdew pointed out, you can do this with diskutil. A good rule of thumb is that if Disk Utility can do it, diskutil can do it. In fact, Apple is great at letting you do anything (and more!) from the command line - for example, the ’softwareupdate’ command for auto-updates.Erase Free Space Windows
The right method to perform this very action is part of diskutil: diskutil secureErase freespace 1|2|3 /dev/disk#s# (See the man page on diskutil) Band-aids never work right. They always peal off!
But that won’t work unless you have root access, right?Not sure if this applies on MacOSxtended, but ext2/3 reserved 5% of space for the root user. If so the rm method would leave 5% untouched if run without privileges. online, free Disk Space
This command does exactly what Disk Utility does. If your computer crashes during a wipe of the free space, you will find that your hard disk space is reduced. Removing the zeroed file from /tmp (if I remember correctly) will restore the disk space. Try doing it in Disk Utility and watch your disk space shrink. As others have pointed out, some disk space is reserved for root, and therefore the chance of a crash is minute. Thanks, robdew, for pointing out the secureErase option of diskutil. Some how I missed that. It does exactly the same thing.
...if you’re concerned about running the aforementioned ’erase free space’ operation on a ’live’ filesystem, you may want to shut down your system and reboot with your OSX install disc and run Disk Utility from there instead. Or, (in keeping with the spirit of the original hint of using the cmd-line) reboot with your OSX install disc into Single User mode (documented elsewhere) then use the diskutil tip mentioned earlier.Just use the diskutil. Open terminal, type df and hit enter. Get the name of your disk (probably /dev/disk0s2) and type the diskutil command to erase free space which is: diskutil secureErase freespace 1 /dev/disk0s2 That will erase your free space with random numbers. See the list of options below: Level should be one of the following: 0 - Single-pass zeros. 1 - Single-pass random numbers. 2 - US DoD 7-pass secure erase. 3 - Gutmann algorithm 35-pass secure erase. 4 - US DoE 3-pass secure erase.
Download here: http://gg.gg/wcn0j
https://diarynote.indered.space
コメント