|Home » Learning Curve
'volfs' is a special Unix file system used by a wide variety of Unix distros. The documentation varies little from platform to platform - most of the time it's identical. The following link explains what it's is all about on Sun Solaris:
Apple have their own variant on volfs, but it's not the same thing. To get a peek into what it's all about, try the following experiment:
- Drop down to a console.
- Go to your Documents directory.
% cd ~/Documents
- Open TextEdit. Type in a bit and save the document as 'volfs.txt'.
- Close TextEdit.
- List your directory.
% ls -il
3415400 -rw-r--r-- 1 you wheel 0 Nov 15 14:32 volfs.txt
- Note the number in the leftmost column: that's the inode. Make sure you keep this number handy.
- Navigate up to the following directory.
% cd /.vol
- That's your 'volfs' volume. Inside this directory you'll have another directory - navigate to it.
% cd new_number
- Remember that inode? Use it now.
% open 3415400
Pretty cool, eh? Note that Unix volfs can't have this feature - if you haven't understood this already, you will.
Apple have a documentation page about their volfs online.
Q: When I run fs_usage against my Carbon application I see lots of accesses to items in the '/.vol' directory. What is this directory and why am I accessing it?
A: This directory is used as the mount point for the 'volfs' file system. The 'volfs' file system is a key component for supporting the Carbon File Manager APIs on top of the BSD file system. Historically, BSD systems only allow you to access a file or directory by its POSIX path. However, the Carbon File Manager API also allows you to access an item by its catalogue node ID (CNID, a file ID reference or a directory ID). 'volfs' provides a bridge between these two models, allowing the Carbon File Manager APIs to work on top of the BSD file system.
What's not mentioned here is that Apple, despite their decision to keep the abortive HFS, must remain 'POSIX compatible'. This means that even if they do not run a good Unix file system (OS X Server does but the workstation version often does not) they have to make it look as if they do.
This means that whatever else they have tied up in their convoluted HFS, it must behave in all respects exactly as a 'real' Unix file system.
But HFS and Unix file systems have an inherent and irrevocable incompatibility - as evidenced by the above. Unix file systems admit of multiple links to the same physical file; HFS is rather unique in basically outlawing such a concept from the get-go.
The traditional HFS APIs for accessing file items have gone into history as some of the most 'up the butt' file system thinking anywhere ever. HFS can only with the greatest difficulty deal in straight paths; HFS wants a file ID and folder ID for any given path; HFS needs special 'crutches' to enable conversion from the obvious and easy way of accessing files to its unbelievably strange and counter-productive method; HFS assumes there is a one-on-one relationship between a physical file and its denoted file name.
There are advantages to this methodology of course, the main being that files can be moved anywhere or renamed to anything and the file system will still find them. MacOS aliases will always work. The deciding factor here is the 'ID' of a file item, which is always constant. Finding this ID is of course another matter, entailing much more code than would be needed on any Unix file system, David Cutler's NT File System, or ordinary mongrel MS-DOS, and neither of the latter have anything against multiple links, even if they don't actively support the 'iblock' concept.
It's now time to continue the experiment.
- Drop back down to a console.
- Go back to your Documents directory.
% cd ~/Documents
- Make a hard link to your 'volfs.txt' file.
% ln volfs.txt volfs1.txt
- List the directory again.
% ls -il
3415400 -rw-r--r-- 2 you wheel 0 Nov 15 14:32 volfs.txt
3415400 -rw-r--r-- 2 you wheel 0 Nov 15 14:32 volfs1.txt
- Note that the numbers in the leftmost column are identical: you have only one physical file on disk - one physical file with two distinct names, which is born out by the '2's in the third column.
These 'multi-links' can occur anywhere on the same physical or virtual device: such a device has but one 'iblock' and any and all files refer into that iblock. You can give a file as many names as you want. This is Unix - get used to it.
- Now navigate back to your '.vol' directory to try the same trick again - but before you do, ask yourself: as there are now two legitimate names for the same ID, which one will your system come up with in TextEdit's title bar? OK, now try the trick.
% cd new_number
% open 3415400
- Did you guess right? Did the 'right' TextEdit window open? What do you think is the general rule here?
The answer is that there is no 'right' answer. Imagine you're speeding down a motorway, with merges happening left and right, and suddenly you realise you're lost and pull off at a petrol stop to ask directions and the attendant says only 'drive back the way you came'. But there are several forks in the road going back; which do you take? And where?
The whole issue is ridiculous because there is no answer; because HFS is incompatible with Unix; because it's a wonder - today an explainable wonder - that the Nexties of Redwood City could ever be lured into such a suicidal 'enhancement' to their system.
Not that the Maccies have been easy to contend with. Here's an example from a developers forum. Read this and keep telling yourself 'this is real; this person really exists'.
'Apple's decision long ago to deprecate toolbox functions which used file paths was a good one. MacOS users can move or rename files/folders/volumes willy nilly without taking a system-wide census of which files are open by what applications. This is no longer true in Mac OS X. I wonder what would have happened if Cocoa had been ported to MacOS. [sic]
'It seems to me that Carbon is a good low-level API while Cocoa is a good high-level API which unfortunately uses POSIX low-level APIs. I'm hoping Apple will introduce a lightweight file primitive like FSRef for Foundation and propogate [sic] its use to methods which currently use POSIX file paths in the form of NSString's, but I'm doubtful.'
It can be noted that this crack (-headed) programmer has an impressive resume published at the same site. His physical location is however not known, so basically no one is safe: keep your doors locked at night.
'Current projects WRT MacOS X:
Fixing Java so Java apps suck less (MacFile)
Fixing Cocoa so Cocoa apps suck less (NSTextView)
Fixing Apache so it doesn't need to use filename extensions (almost dead project) [sic]'
NeXTSTEP was and is and will continue to be brilliant; almost every seasoned NeXTSTEP programmer knows this and supports the system in its pristine form.
It is equally agreed that any foibles OS X has today are the direct result of concessions the Nexties Jobs brought to Cupertino have made to the Maccies already there.
But something's got to give. One cannot continue to put the cart before the horse, or to hitch the horse backwards to the cart, or to try to force square pegs into round holes, or to pretend that HFS is a good and consistent Unix file system.