"rm -P" on HFS+

[Micah L]

The -P option when using rm is supposed to overwrite files before they are deleted. The man page, however, has this to say:

The -P option assumes that the underlying file system is a fixed-block file system. UFS is a fixed-block file system, LFS is not. In addition, only regular files are overwritten, other types of files are not.

Does anyone know whether or not HFS+ is a fixed-block file system? I managed to find this page with Google that would seem to suggest so, but I thought I should ask since it is pretty vague on the subject and is a little old. Also, I'd assume virtually every file is a "regular file," anyone have something to say contrary to this assumption? I started putting together a little Cocoa GUI wrapper to handle this, so obviously this is a pretty big issue since I need it to actually work .

 

[ladavacm]

Originally posted by Micah L
The -P option when using rm is supposed to overwrite files before they are deleted. The man page, however, has this to say:

-P is not actually implemented, AFAIK.

HFS+ is a block based filesystem.

Not all UNIX filesystem objects are regular files: exceptions are directories (obviously), device files, symbolic links, (UNIX) sockets, and named pipes.

 

[Micah L]

Originally posted by ladavacm


-P is not actually implemented, AFAIK.

Hmm, according to the FSF fileutils page you're right. However, shred is listed there as a utility to overwrite files repeatedly and it seems to be working after a quick "sudo apt-get install fileutils" through fink. Of course, there's no recursive flag for it, but there could be ways around that. Thanks for the heads up, you probably saved me a lot of work if I keep coding this program.

 

[strobe]

Furthermore you wouldn't be scrambling all the info. HFS+ supports more file attributes than 30yr old UNIX programs do.

 

[Micah L]

Originally posted by strobe
Furthermore you wouldn't be scrambling all the info. HFS+ supports more file attributes than 30yr old UNIX programs do.

True, but the essential data of the file is gone. This wont be everything (like you said) but the most important part is gone, the rest isn't something that people are extremely likely to need gone.

 

[Micah L]

Originally posted by testuser
if someone wants to irretrevable destroy jpegs, they might use your program. If someone comes along at a later date and snoops on the hard drive, they might be able to retrieve thumbnails of all the jpegs. This data can be stored in the resource fork.

That's sort of a worst case scenario, but my main aspiration was to offer a free solution to a problem that (after a search on verisontracker) doesn't appear to be one that is easily solved or done so well in many cases. With the case of many text files which could include credit card numbers, personal information, etc, the resource fork tends to be much less dangerous. If users are told of the vulnerabilities, I think they'll be careful to avoid problems caused by them. I'm not saying that it will be a perfect, or maybe even a very good solution, but it offers something. I may not even find myself releasing anything, so I guess time will tell.

 

[strobe]

Not only will you fail to erase thumbnails, but also the resource fork, creation dates, file type/creators, comments, etc.

A tool which approaches what you're looking for is Burn, but it hasn't been carbonized and is still written for 31 character filenames.