Re: FSRef speed impacts and permission checks
Re: FSRef speed impacts and permission checks
- Subject: Re: FSRef speed impacts and permission checks
- From: "James W. Walker" <email@hidden>
- Date: Thu, 15 May 2008 08:03:16 -0700
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? _______________________________________________
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