Of course, we all are good developers, and hack - is not our way. But time by time ...




Well this little post is about my investigation of HFS+ filesystem. It was developed by Apple, and mostly known as an OSX's main filesystem. Last several months i had a lot of work, related to investigation and re-implementation of Apple's low-level technologies (like filesystem's support, and some EFI-related stuff), and that time i was trying to fix bug in my HFS+ support implementation code, and this encourages me to read this filesystem's specification more accurately.


One fact seemed weird for me even at first read of spec: the filesystem contained information about files' appearance in Finder. The filesystem contains info about icons, it's place on screen and so one and so on. The filesystem contains description of all thingies for every file in filesystem. These guys really think different (c).

This fact is interesting, but the questionable architectural solution is not good enough reason for writing a post. This post is more philosophical: it's about the broken windows theory.

This architectural decision is not extremely horrible. In practice this is even a nice decision to live some time with it.. The problem is, that the bad design leads to worse solutions in future: you open a pandora's box, and can't be sure, that this cute tiny lizard will not grow up to hydra. I'm sure, that the architect, who decided to include Finder's meta info into the filesystem, didn't think that the next generations of developers will make some wild kludges, using these feature of filesystem.

As all good filesystem, the HFS+ support hard links. Without going into details, it stores an metadata about hard links' machinery inside the folder, named "HFS+ Private Data". And this folder has location of corresponding icon in finder (22460,22460). Can you guess, what the reason for this? Right! The only reason to do it is to protect this folder from the accidental changes of metadata. This is fantastic!



When i was young, i used this protection technique to protect some vulgar docs from accidental changes. Also I used to add the second layer of protection, using undocumented abilities of NTFS: path like  C:/New folder/New folder(2)/New folder(4)/NewFolder. Worked well enough too.

Yes, from the other hand you shouldn't take it too seriously: if you support HFS+ filesystem, you should do something more to protect this data. But if this guys writes in specification about this trick, then they gives some sense to this stuff. And this frightens me very much: they are responsible for security of my files, and who knows, what else they can invent for my protection...