Re: Determining if a volume support
Re: Determining if a volume support
- Subject: Re: Determining if a volume support
- From: Jim Luther <email@hidden>
- Date: Tue, 19 Feb 2008 09:51:51 -0800
On Feb 19, 2008, at 7:15 AM, James Bucanek wrote:
Quinn <mailto:email@hidden> wrote (Tuesday, February 19, 2008
2:47 AM -0000):
Alternatively, if you're working at the File Manager level, you can
get the same information via FSGetVolumeParms. Look for the
bSupportsExtendedFileSecurity bit in the vMExtendedAttributes field.
Thanks, Quinn.
Good news: I'm not going blind.
Bad new: This isn't documented. I'll file a bug report.
--
James Bucanek
When bSupportsExtendedFileSecurity is set for a volume, you can use
FSGetCatalogInfo and ask for the kFSCatInfoFSFileSecurityRef info and
you may (or may not if there isn't an ACL for the item) get a
FSFileSecurityRef when you ask for it. When
bSupportsExtendedFileSecurity is clear for a volume, asking for
kFSCatInfoFSFileSecurityRef will always return NULL for the
FSFileSecurityRef.
You'll get the correct results no matter if a volume supports
FSFileSecurity objects or not. So, if your code is going to call
FSSGetCatalogInfo for other catalog info, asking for
kFSCatInfoFSFileSecurityRef *when you need it* doesn't cost you
anything.
Here's a code snippet:
FSCatalogInfo catalogInfo;
FSPermissionInfo *permissionsInfo;
acl_t accessControlList;
// Get the FSFileSecurityRef for the target
result = FSGetCatalogInfo(target, kFSCatInfoFSFileSecurityRef,
&catalogInfo, NULL, NULL, NULL);
require_noerr(result, FSGetCatalogInfo_failed);
// See if there is a FSFileSecurityRef
permissionsInfo = (FSPermissionInfo *)&catalogInfo.permissions;
require_quiet(permissionsInfo->fileSec != NULL, ACLsNotSupported);
// Copy the existing ACL if any
result = FSFileSecurityCopyAccessControlList(permissionsInfo-
>fileSec, &accessControlList);
if ( result == noErr )
{
// use the bsd routines to work with the ACL
...
// free the memory used by the ACL
acl_free(accessControlList);
}
// release the FSFileSecurityRef
CFRelease(permissionsInfo->fileSec);
ACLsNotSupported:
FSGetCatalogInfo_failed:
- Jim Luther
* Note: Some catalog information is more expensive to get than others.
For performance reasons, your code should only ask for what it really
needs (don't ask for kFSCatInfoGettableInfo unless you REALLY need
it). Object names and types (kFSCatInfoNodeFlags) are the cheapest
information to get. The information returned by stat/stat64 is the
next cheapest because file systems have been optimized to return these
attributes.
Getting this information is more expensive on volume formats that do
not support the corresponding getattrlist attributes natively:
kFSCatInfoFinderInfo (ATTR_CMN_FNDRINFO)
kFSCatInfoFinderXInfo (ATTR_CMN_FNDRINFO)
kFSCatInfoRsrcSizes (ATTR_FILE_RSRCLENGTH)
Getting security information beyond simple POSIX permissions is
expensive:
kFSCatInfoUserAccess
kFSCatInfoFSFileSecurityRef
On volumes that don't support the getattrlist attribute
ATTR_DIR_ENTRYCOUNT, kFSCatInfoValence is VERY expensive:
kFSCatInfoValence (ATTR_DIR_ENTRYCOUNT)
_______________________________________________
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