Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Secure Deletion' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Secure Deletion
Authored by: Cadre on Apr 11, '02 03:25:06PM

It should be noted that the -P flag only works on fixed-block filesystems, which I believe HFS+ is not. If you use UFS, it should work as advertised though.

[ Reply to This | # ]
Secure Deletion
Authored by: imacusr on Apr 11, '02 04:07:53PM
Do you happen to know if shred would work properly on HFS+?

[ Reply to This | # ]
Works fine on HFS+ (or not??)
Authored by: sjonke on Apr 11, '02 05:46:49PM

Or at least it seems to work fine on my PowerBook and it has an HFS+ formatting. What would be the behavior of it NOT working? Would it still delete, but not do so securely? If that is the case, then I'll pull this, because that would be a very bad thing, to think something was securely deleted when it was not.


[ Reply to This | # ]
Looks like HFS+ is fixed-block size
Authored by: sjonke on Apr 11, '02 06:01:05PM
From reading Apple's developer page on HFS+, it looks to me like HFS+ is fixed-block, it's simply more efficient than HFS because there are more blocks available to spread over the whole disk (32-bits worth instead of 16):
HFS divides the total space on a volume into equal-sized pieces called allocation blocks. It uses 16-bit fields to identify a particular allocation block, so there must be less than 216 (65,536) allocation blocks on an HFS volume. The size of an allocation block is typically the smallest multiple of 512 such that there are less than 65,536 allocation blocks on the volume (i.e., the volume size divided by 65,535, rounded up to a multiple of 512). Any non-empty fork must occupy an integral number of allocation blocks. This means that the amount of space occupied by a fork is rounded up to a multiple of the allocation block size. As volumes (and therefore allocation blocks) get bigger, the amount of allocated but unused space increases. HFS Plus uses 32-bit values to identify allocation blocks. This allows up to 2 32 (4,294,967,296) allocation blocks on a volume. More allocation blocks means a smaller allocation block size, especially on volumes of 1 GB or larger, which in turn means less average wasted space (the fraction of an allocation block at the end of a fork, where the entire allocation block is not actually used). It also means you can have more files, since the available space can be more finely distributed among a larger number of files. This change is especially beneficial if the volume contains a large number of small files.
However, that's just my reading of it. I don't claim to be an expert. They don't explicitly use the phrase, "fixed-block" anywhere that I can find. Anyone know for certain?

[ Reply to This | # ]
Looks like HFS+ is fixed-block size
Authored by: jlowrey on Apr 12, '02 01:50:41AM

I wrote Trash X. When I added file shredding features to it, I relied on "rm -P" to handle the task. This was an embarassing mistake. In short, "rm -P" does not reliably shred files on HFS+ volumes. In my tests, it only worked on HFS+ in situations where the file to be shredded was larger than the available free space. In all other cases with HFS+, "rm -P" merely deleted the file without overwriting it. It is interesting to note however that "rm -P" takes longer to execute than just "rm". I believe that on HFS+ disks, "rm -P" essentially deletes the old file and creates a new file on each pass and writes its data sequence into it, but that is just conjecture on my part.

It upsets me to see "rm -P" so frequently touted as a CLI file shredding option. The reality is that most OS X users are using HFS+ partitions, and that is what Apple ships out of the box. For the majority of OS X users, "rm -P" is not a viable option.

And now the shameless plug. To my knowlege, Trash X is the only OS X GUI file shredder that offers support for files larger than 2 GB, and supports shredding freespace on disks.



[ Reply to This | # ]