Re: Status of getdirentriesattr()?
Re: Status of getdirentriesattr()?
- Subject: Re: Status of getdirentriesattr()?
- From: James Bucanek <email@hidden>
- Date: Mon, 10 Sep 2012 13:49:02 -0700
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