Rename folder with odd characters

Question

I have a folder on my Mac called "␀␀␀␀HFS+ Private Data". I'm trying to delete it but it contains a bunch of odd characters that are choking unlink, rm and mv, making it difficult to remove it and its contents. I've tried whipping up some code to call unlink() directly just in case unlink/rm/mv binaries are doing some other stuff - but no, unlink() can't parse this character.

I used echo and od to figure out what character this is:

************@Trinity:~/Desktop/test$ echo -e "␀" | od -t oC -An
      342 220 200 012`

I looked up 342 here: http://ascii-code.com - and found that it's part of the Latin-1 set. I tried iconv to convert it to UTF-8:

************@Trinity:~/Desktop/test$ iconv -f latin1 -t utf-8 "␀␀␀␀HFS+ Private Data"
iconv: ␀␀␀␀HFS+ Private Data: I/O error

So how do I delete this folder? Can I pass hex/oct codes to rm or mv or something? I've tried everything I can think of, including rm *, invoking sudo, etc. The problem is that unlink chokes on that character, so I need to change that character somehow. I was also thinking about installing Debian in a VM and giving it access to this folder so that I could try from there, in case this is an issue with the tools I have in my OS X environment.

EDIT: I tried this:

************@Trinity:~/Desktop/test$ echo -e "␀␀␀HFS+ Private Data" | od -t oC -An
      342 220 200 342 220 200 342 220 200 110 106 123 053 040 120 162
      151 166 141 164 145 040 104 141 164 141 012`

************@Trinity:~/Desktop/test$ echo "\342\220\200\342\220\200\342\220\200\110\106\123\053\040\120\162\151\166\141\164\145\040\104\141\164\141\012" | xargs rm

rm: 342220200342220200342220200110106123053040120162151166141164145040104141164141012:     No such file or directory

************@Trinity:~/Desktop/test$ echo "\342"
\342

EDIT2: showing the unlink() error

************@Trinity:~/Desktop/test$ unlink test3.txt
************@Trinity:~/Desktop/test$ unlink "␀␀␀␀HFS+ Private Data/1.txt"
unlink: ␀␀␀␀HFS+ Private Data/1.txt: Invalid argument
************@Trinity:~/Desktop/test$ cd "␀␀␀␀HFS+ Private Data/"
************@Trinity:~/Desktop/test/␀␀␀␀HFS+ Private Data$ unlink 1.txt
unlink: 1.txt: Invalid argument

EDIT3: showing that it's not an HFS+/filesystem issue, but rather a filename issue

************@Trinity:~/Desktop/test$ mkdir "␀␀␀␀testTest"
************@Trinity:~/Desktop/test$ rm -r "␀␀␀␀testTest"
rm: ␀␀␀␀testTest: Invalid argument

EDIT4: this might be progress... I'm going to mess with the locale next.

************@Trinity:~/Desktop/test$ ls | grep -i *test* | xxd
0000000: e290 80e2 9080 e290 80e2 9080 7465 7374  ............test
0000010: 5465 7374 0a                             Test.

************@Trinity:~/Desktop/test$ rm -r $'\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\x74\x65\x73\x74\x54\x65\x73\x74\x0a'
rm: ␀␀␀␀testTest
: No such file or directory

Follow-up to this: nope, false hope.  I dropped the \x0a on the end and it 'worked'... kind of.

************@Trinity:~/Desktop/test$ rm -r $'\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\x74\x65\x73\x74\x54\x65\x73\x74'
rm: ␀␀␀␀testTest: Invalid argument

Answer 1

According to https://apple.stackexchange.com/questions/31734/hfs-private-directory-data that folder is used for filesystem inner workings. You probably can't delete it and, even if you could, it would most likely brick your filesystem.

Answer 2

I know that this has already been resolved for OP, but for anyone stumbling upon this question, this seems to be a 10.11 El Capitan only problem. I tried and was able to delete files with this character in OS X 10.4 Tiger and OS X 10.10 Yosemite, so it very likely works on the other ones.

Answer 3

Just an FYI:

The "␀␀␀␀HFS+ Private Data" folder is an HFS+ special folder that is used to hold the actual file-data and meta-data for hard-linked files.

So multiple directory-entries point to a 'file' in this hidden directory, which in turn has the actual file-data and atributes attached.

It has some special attributes like the four leading ZERO characters in the name, as well as a few other bits in its meta-data to make it very unlikely it is ever 'seen' by the end-user in normal use.

When found in some backup (so no live copy) as a visible folder you can safely remove it, if the system allows you to do so (perhaps after low-level renaming with a hex-editor or other tool.

There is a similar hidden file called ".HFS+ Private Directory Data" that is used to store hard-link info on folders.

Answer 4

Have you tried simply renaming the folder to something else then deleting it?

A method that has worked for me was to live boot into a Linux environment via CD/USB, dismount the drive with the 'odd' named directory/file, THEN deleting it. This method works most of the time, not every, for me.

Answer 5

It looks like there's a (retired?) spec here:

Indirect node files exist in a special directory called the metadata directory. This directory exists in the volume's root directory. The name of the metadata directory is four null characters followed by the string HFS+ Private Data. The directory's creation date is set to the creation date of the volume's root directory. The kIsInvisible and kNameLocked bits are set in the directory's Finder information. The icon location in the Finder info is set to the point (22460, 22460). These Finder info settings are not mandatory, but they tend to reduce accidental changes to the metadata directory. An implementation that automatically follows hard links should make the metadata directory inaccessable from its normal file system interface.

Note:

The case-insensitive Unicode string comparison used by HFS Plus and case-insensitive HFSX sorts null characters after all other characters, so the metadata directory will typically be the last item in the root directory. On case-sensitive HFSX volumes, null characters sort before other characters, so the metadata directory will typically be the first item in the root directory.

POSIX semantics allow an open file to be unlinked (deleted). These open but unlinked files are stored on HFS Plus volumes much like a hard link. When the open file is deleted, it is renamed and moved into the metadata directory. The new name is the string "temp" followed by the catalog node ID converted to decimal text. When the file is eventually closed, this temporary file may be removed. All such temporary files may be removed when repairing an unmounted HFS Plus volume.

Repairing the Metadata Directory

When repairing an HFS Plus volume with hard links or a metadata directory, there are several conditions that might need to be repaired:

• Opened but deleted files (which are now orphaned).

• Orphaned indirect node files (no hard links refer to them).

• Broken hard link (hard link exists, but indirect node file does not).

• Incorrect link count.

• Link reference was 0.

Opened but deleted files are files whose names start with "temp", and are in the metadata directory. If the volume is not in use (not mounted, and not being used by any other utility), then these files can be deleted. Volumes with a journal, even one with no active transactions, may have opened but undeleted files that need to be deleted.

Detecting an orphaned indirect node file, broken hard link, or incorrect link count requires finding all hard link files in the catalog, and comparing the number of found hard links for each link reference with the link count of the corresponding indirect node file.

A hard link with a link reference equal to 0 is invalid. Such a hard link may be the result of a hard link being copied or restored by an implementation or utility that does not use the permissions in catalog records. It may be possible to repair the hard link by determining the proper link reference. Otherwise, the hard link should be deleted.

Answer 6

Spent some time with Apple Support on this and they told me the only answer was to do a Time Machine backup of my volume, wipe the original volume, create a new user account and then selectively copy all my files over manually from the Time Machine backup. Realizing the work this would entail in restoring my wonderfully complex account with all my preferences, setups, software authorisations, scripts, handy utilities, etc, I didn't want to do that so I had another idea that worked for me.

I worked out that I could move the immediate folder above the undeleteable file, so I corralled all the files I had with the null characters that nothing would allow me to delete them with into another folder, and then created a Carbon Copy Cloner clone of my entire boot HDD, but excluding the folder with the undeleteables. I then booted into this disk, reformatted my original disk, and restored the clone, sans the undeletable files.

When someone works out how to make the various Unix based OSes deals with these file names, we'll all be very happy, but in the meantime, CCC to the rescue for me.