Re: FSRef speed impacts and permission checks
Re: FSRef speed impacts and permission checks
- Subject: Re: FSRef speed impacts and permission checks
- From: Mark Day <email@hidden>
- Date: Thu, 15 May 2008 09:50:59 -0700
On May 15, 2008, at 8:03 AM, James W. Walker wrote:
On May 14, 2008, at 5:29 PM, Mark Day wrote:
An FSRef is not the same as an open file descriptor. It's more
like shorthand for a pathname. In fact, the File Manager uses what
we call a "VolFS" pathname that identifies the volume and parent
directory numerically (much like an FSSpec from The Old Days™).
In older versions of Mac OS X, there was a separate file system
called "volfs" that found the appropriate vnode for the given
directory ID (much like the way the NFS file server resolves file
handles). Then volfs had to walk back up the parent hierarchy to
make sure the caller would have permission to access the given
item; these checks were separate from the normal pathname processing.
In current versions of Mac OS X (I think 10.4 and later), the volfs
file system was removed. Now, volfs-style pathnames are parsed by
VFS and turned into a full pathname inside the kernel (by walking
up the vnodes' parent pointers). Then it walks down the path as if
the caller had passed a full pathname, which lets us leverage the
existing permission checks. (As Dominic pointed out, there is
caching to reduce the cost of those permission checks.)
I'm not a file system developer, so this might be a dumb question...
If processing an FSRef involves creating a full pathname, then how
come using FSRefs can avoid the 1024-byte limit on length of full
pathnames?
Not a dumb question at all. The actual path passed into the kernel is
much shorter. It might look like "/.vol/234881029/6037/Hello World".
It gets transformed into a full path inside the kernel. Also, the
kernel generally allows pathnames coming in to be larger than PATH_MAX
(though many libraries assume a maximum of PATH_MAX, and are incapable
of dealing with larger paths).
-Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden