FSRef speed impacts and permission checks
FSRef speed impacts and permission checks
- Subject: FSRef speed impacts and permission checks
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 15 May 2008 00:32:35 +0200
- Thread-topic: FSRef speed impacts and permission checks
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:
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
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
such a permissions change?
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.
Can someone explain these or is there some info on this? Is the
CatalogSearch implementation part of the open source Darwin code?
Thomas
_______________________________________________
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