Re: FSRef speed impacts and permission checks
Re: FSRef speed impacts and permission checks
- Subject: Re: FSRef speed impacts and permission checks
- From: Dominic Giampaolo <email@hidden>
- Date: Wed, 14 May 2008 15:37:18 -0700
While I have recently shown how much faster the Carbon File Mgr
based FSRef
methods are compared to POSIX path based functions, there are still
some
mysteries about FSRefs for me:
I would be very interested to see any performance numbers
or tests that you ran that show this difference.
Even if a FSRef can point directly to the HFS Node on disk, the OS
must
still ensure that all its parent dirs' permissions are met, right?
While I
suspect that this check is done only once when the FSRef is created,
what if
That is correct and how it has worked for the last 3 or 4
years.
the permissions of a parent dir get changed while the app keeps
running -
the FSRefs would then need to be re-evaluated. How is that achieved,
i.e.
what mechanisms are used internally to know which FSRefs are
affected by
That is not correct - no OS that I know of will re-evaluate
all open file descriptors on a permission change. It's not
practical nor do I think it is desirable. You can't just go
and revoke an application's open file descriptor because some
directory above it changed permissions.
In a similar way, how are permissions, especially the "directory
browse"
flag, ensured with CatalogSearch? If CatalogSearch runs over the HFS
Dir
Nodes sequentially, each time it wants to return a node, it needs to
check
its parents' browse permissions. But that would defy the whole idea of
CatalogSearch's speed advantage.
We use basic caching techniques to mitigate the cost of doing
the permission checks. The code is all there in xnu/bsd/hfs/
if you want to go read it :-)
--dominic
_______________________________________________
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