Getting Around HFS+ Private Data

Passion is the enemy of precision.
 - Daryl Zero

Get It Try It

Try this on TextEdit and you'll be fooled: Ali's got special code in there to get around this - silently.

Start by firing up GDE and then TextEdit. Put GDE in HFS+ Private Data to watch.

Then go back to TextEdit. Type something in.

Then save the file. Then go to a terminal and list it.

$ ls -ailoT Untitled.rtf
4797622 -rw-r--r--   1 rixstep  staff  - 378 Sep  3 12:27:14 2007 Untitled.rtf

Make a note of the inode.

Stay at your terminal - and make a hard link to the file.

List again.

$ ls -ailoT Untitled*.rtf
4797622 -rw-r--r--   2 rixstep  staff  - 378 Sep  3 12:27:14 2007 Untitled-linked.rtf
4797622 -rw-r--r--   2 rixstep  staff  - 378 Sep  3 12:27:14 2007 Untitled.rtf

Note they both still have the same inode. Now go to GDE and refresh its view.

Looks like you got a new item in there. Pick up the inode on the find pasteboard and search for it in GDE.

There it is! Now go back to TextEdit and make a trivial change in the file. Get the red button dirty.

Now save the file. It should work OK as Ali's got special code in there to sidestep the issue. Ali's not specifically looking for hard links - at least that's not what he says. He says he's only looking for 'difficulties'. But hard links are in this context a difficulty. So save the file. And it saves, right? OK, go back to Terminal and list those files again.

$ ls -ailoT Untitled*.rtf
4797622 -rw-r--r--   1 rixstep  staff  - 378 Sep  3 12:27:14 2007 Untitled-linked.rtf
4797635 -rw-r--r--   1 rixstep  staff  - 437 Sep  3 12:35:19 2007 Untitled.rtf

Oops! The linked file still has the same inode but the original's changed! What does GDE say? Yep - the inode's still listed in there even though the file is no longer hard linked.

Why is that? It's because once a file is 'banished' to HFS+ Private Data it can never come back. Never. It's lost forever.

You can try opening the linked file in TextEdit and saving it again - and again the inode will change. Because TextEdit can't modify files that have moved into HFS+ Private Data. It doesn't specifically look for this but if it encounters 'difficulties' it eradicates the current file and creates a new one. Check back with GDE again and you'll see the file's been moved to the 'temp' category.

OK, kill TextEdit and get rid of those two files. Take another standard application that's not been customised to get around HFS+ Private Data. Preview for example. Create a simple small screenshot with ⇧⌘4. It'll end up on your desktop. Move it to ~/Documents. List it in the terminal. Note the inode.

$ ls -ailoT *.png       
4797659 -rw-r--r--   1 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1.png

You can search for this inode in GDE but you won't find it - it's not hard linked yet. Open the file with Preview.

Then back to the terminal, hard link the file, and list again. Note the inode is still the same - for both files.

$ ln Picture\ 1.png Picture\ 1-linked.png
$ ls -ailoT *.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1-linked.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1.png

Go into GDE and search for the inode now. Bingo.

OK, back to Preview and twist the image or something to get the red button dirty.

Now save the file.

Whoever wrote Preview didn't put in any extra code to get around HFS+ Private Data.

Is all lost? Mostly but not quite. Copy Picture 1.png to Picture 2.png.

List again.

$ ls -ailoT *.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1-linked.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1.png
4797696 -rw-r--r--   1 rixstep  staff  - 6431 Sep  3 12:59:36 2007 Picture 2.png

Both links to the original are the same; Picture 2.png has its own inode. As it should be. Now open Picture 2.png in Preview, twist the image, and save it. This will work as Picture 2.png isn't hard linked.

Now back to the terminal and list again.

$ ls -ailoT *.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1-linked.png
4797659 -rw-r--r--   2 rixstep  staff  - 6431 Sep  3 12:44:21 2007 Picture 1.png
4797696 -rw-r--r--   1 rixstep  staff  - 6398 Sep  3 13:01:35 2007 Picture 2.png

The inodes are the same but the size of Picture 2.png not surprisingly changed. OK, now copy Picture 2.png to your choice of either of the other two and list again.

$ cp Picture\ 2.png Picture\ 1.png
$ ls -ailoT *.png
4797659 -rw-r--r--   2 rixstep  staff  - 6398 Sep  3 13:03:43 2007 Picture 1-linked.png
4797659 -rw-r--r--   2 rixstep  staff  - 6398 Sep  3 13:03:43 2007 Picture 1.png
4797696 -rw-r--r--   1 rixstep  staff  - 6398 Sep  3 13:01:35 2007 Picture 2.png

Note that all three inode listings are the same but the sizes for both links to the original have changed - the file sizes are now all identical because the one copy operation affected both links to the original file. And finally for a treat open the original - using either name - in Preview again.

There are ways around everything.

See Also
GDE-FAQ
GDE: Peekaboo
GDE Screenshots