that's exactly why i asked. he said he tried rm and sudo rm. naturally an rm won't work on a dir with files.

he skipped right over rm -rf. according to what he says he did. i ask since this has worked for me before.

Look at what is in the "code" box - it shows that he tried 'rm -rf bene'
I presume that (according to post #4) he then did 'sudo rm -rf bene'

This is not the only time we've encountered a problem like this with files that are undeletable due to strange characters.
See: http://forums.macosxhints.com/showthread.php?t=15814

oh, how did i miss that.

thanks

I'm still getting filesystem corruption vibes. Really, really strong ones, too....

Cheers,

b&

You might get that impression given some of the "symptoms", but the earlier posts confirm the presence of "odd" encodings in the filenames, and this issue has come up a number of times on all sorts of Mac forums. A few years ago, a simple solution was to boot into System 9 (which seems to be able to handle more odd encodings than OS X) and delete the file from there. More recent Macs can't boot in System 9 so obviously that is no longer an option, though I wonder if attaching it to an older Mac via target disk mode would work... Someone mentioned using Disk Warrior to fix encodings - I haven't heard whether that works or not, but it would be a shame if money had to be spent to fix a problem that can be caused by just transferring a file to your computer...

Let me re-phrase.

If you have an inode that can't be deleted or renamed, the filesystem IS corrupt. Period.

Now, it may be that, in this particular case, the reason the files can't be deleted or renamed is because their filenames have illegal characters not permitted by the HFS+ spec--an archetypal form of corruption. It may also be that the filesystem is theoretically okay, that the spec permits such filenames, but that all the standard libraries and utilities are broken in such a way that they can't deal with all valid filenames--in which case, one is left to wonder how the file got created with that name in the first place. Either way, it doesn't matter.

What does matter is that this is a very, very serious bug. Filesystem corruption of any kind is serious bad mojo. If this is something that can be reproduced, especially if it can be done without doing anything particularly unusual, it's also a major security hole.

Frankly, it sounds like it'd be near-trivial to fill up a filesystem by creating a super-large file that can't be deleted. Or by creating millions of small files that can't be deleted, either. That in and of itself constitutes a really, really nasty DOS attack that'd be difficult or impossible to protect against in many real-world situations. (Yeah, quotas, partitioning, etc.) Considering how poorly OS X and other systems that allocate swap dynamically handle low disk situations...this is about as bad as they come.

Has anybody bothered to tell Apple about this? Is anybody from Apple listening?

What's the best way to report security problems to Apple?

Cheers,

b&

You might be under the misapprehension that the HFS+ filesystem has inodes as the fundamental entities. That is not correct. While there is an inode number for each file (e.g. as shown by 'ls -i'), that is merely an attribute added for backward compatibility with traditional Unix utilities. The fundamental handle (means of referring to a file) is the filename, not the inode number.
See:
http://developer.apple.com/technotes/tn/tn1150.html
http://www.usenix.org/publications/l.../sanchez_html/

It is obviously a bug. Some gatekeeper routine that is supposed to check for valid characters is failing to do its job. Once the file is there, the various utilities are failing because they have built-in assumptions about the possible characters. I think these files are getting in via some sort of filesharing from a non-OSX system.

I don't think it's a security hole since you would need permission to create the file in the first place.

It is unlikely that anyone in Apple engineering reads these forums.
It would be nice to report this bug but I think first what we need is a way to reproduce it. That is why I was trying to find out exactly what characters were in those troublesome filenames and why I tried (without success) to create a file of that name on my system.

Security issues, like other bugs, can be reported via Apple's bug report form:
http://developer.apple.com/bugreporter/bugrptform.html

There're lots and lots of situations where semi-trusted users have exactly that permission. Labs in servers, for example, as well as most Web, ftp, etc. servers that accept files for upload. You can also perhaps create archive files with bad names in them, email things to people....

Yeah...that's the kicker. I'm sure sending proof-of-concept code would get their attention much better than just ``files with weird characters in their names can't be deleted,'' which is what we're stuck with currently.

Hmmm...here's a thought. You (or somebody else?) mentioned that you could use OS 9 to delete the files? Perhaps they're easier to create in OS 9. If so, here's a suggestion:

Create a file on a computer running OS 9. If possible, get that file onto a read-write disk image that has the problem. If not, get the file onto a cheap thumb disk. Confirm that OS X has the problem. Then, send get the disk image or the thumb disk to Apple, along with an appropriate write-up. That should get their attention.

I'd offer to help...but I don't have anything that'll boot OS 9 anymore.

Of course, it could still just be ye olde fashioned filesystem corruption....

Cheers,

b&

PS Perhaps manually creating a UU-encoded file would be an easy way to trigger this? Editing a tarball or a zip file? b&