Re: Status of getdirentriesattr()?
Re: Status of getdirentriesattr()?
- Subject: Re: Status of getdirentriesattr()?
- From: Shantonu Sen <email@hidden>
- Date: Mon, 10 Sep 2012 13:57:13 -0700
Sounds like you did not install the Command Line Tools package from within Xcode, which is where section 2 man pages come from
Sent from my iPhone
On Sep 10, 2012, at 1:49 PM, James Bucanek <email@hidden> wrote:
> Jim,
>
> It's good to hear from you.
>
> Jim Luther <mailto:email@hidden> wrote (Friday, September 7, 2012 3:22 PM -0700):
>> James,
>>
>>> Can anyone tell me the status of getdirentriesattr()?
>>
>> As far as I know, getdirentriesattr(2) is not deprecated.
>>
>>> One document says it's deprecated in 10.6. Another one doesn't say anything. Yet, in the docs included in Xcode 4.4.1 it's been removed from the documentation entirely.
>>
>> Could you let me know where it is said to be deprecated?
>
> My bad. It's not deprecated. getdirentries() is deprecated. getdirentriesattr() is just missing from the Xcode 4 documentation set.
>
>> I don't know why it's not in the Xcode documentation set.
>
> I don't know either, but I did find this comment in the getdirentriesattr() man page from 10.6/7: "The getdirentriesattr() function has been undocumented for more than two years."
>
> So I don't know what's going on with its documentation, but I've filed a bug report requesting that getdirentriesattr() be included.
>
>> There's a man page for it:
>> man 2 getdirentriesattr
>
> There is/was in 10.6 or maybe 10.7, but a clean install of 10.8 doesn't have any section 2 man pages. I was using the one I had left over from a previous OS. So since there is zero documentation for getdirentriesattr() in Mountain Lion and Xcode 4, I was starting to get a little nervous about using it. :)
>
>>> It's also stated that it's not supported on all filesystems.
>>
>> That is true. It's only supported on file systems that set the VOL_CAP_INT_READDIRATTR capability bit.
>>
>> In addition to that limitation, getdirentriesattr(2) does not support the attributes ATTR_CMN_EXTENDED_SECURITY, ATTR_CMN_UUID, ATTR_CMN_GRPUUID, and ATTR_CMN_FULLPATH so if you need any of those attributes, you'll have to use getattrlist(2). ATTR_CMN_EXTENDED_SECURITY, ATTR_CMN_UUID, ATTR_CMN_GRPUUID are only supported by file systems that set the VOL_CAP_INT_EXTENDED_SECURITY capability bit.
>
> Thank's for the clarification (and I wish that info was in the man page too). I do need some of those, but not as part of my basic directory scan. so I can get them piecemeal as needed.
>
>>> Second question: is the only alternative to use readdir() to get an entry, construct a complete pathname to the item, and then use getattrlist() to obtain the metadata? Something akin to this loop:
>>
>> Yes, that's what you'll need to do.
>
> I've done both now (since I need a fall back for volumes where getdirentriesattr() isn't supported). The performance advantage was worth the effort. In most of my testing, the getdirentriesattr() version is slightly more than twice (!) as fast as any combination of readdir()/getattrlist(). So, yay!
>
>> Check out fts(3). It does that work for you nicely. Tools like find(1) are built on fts(3).
>
> I like fts(), but there's just enough of an impedance mismatch between it and the Obj-C objects that I need to manage my directory trees than I decided not to use it. Besides, it doesn't appear that fts() will get me all of the metadata I need in one pass, which means that I'll still end up calling getattrlist() for every entry, which sort of squashes the performance.
>
>>> Finally, do I need to be worried about _DARWIN_FEATURE_64_BIT_INODE? Casual testing would indicate that it's always defined, so
>> regardless of whether I'm compiling 32- or 64-bit code, the structs and functions will still use the 64-bit inode structures (which is clearly what I want).
>>
>>
>> Use:
>> man 2 stat
>> and look for _DARWIN_FEATURE_64_BIT_INODE. That's the non-obvious place where you'll find the documentation for _DARWIN_FEATURE_64_BIT_INODE.
>
> Thanks you very much for that tip! I'd seen the brief discussion of _DARWIN_FEATURE_64_BIT_INODE in dir(5), which is what prompted my question. The documentation in stat(2) is just what I was looking for.
>
> James
> --
> James Bucanek
>
>
> _______________________________________________
> 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
_______________________________________________
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