Re: Counting the number of files in a directory
Re: Counting the number of files in a directory
- Subject: Re: Counting the number of files in a directory
- From: Alastair Houghton <email@hidden>
- Date: Fri, 9 Mar 2007 15:35:15 +0000
On 7 Mar 2007, at 01:17, Rob Keniger wrote:
On 06/03/2007, at 14:20, Chris Suter wrote:
FSGetCatalogInfo is likely to be considerably more efficient on HFS
+ volumes.
What happens if you call this on a mounted network volume? The docs
say:
"Many volume formats do not store a field containing a directory’s
valence. For those volume formats, this field is very expensive to
compute. Think carefully before you ask the File Manager to return
this field."
Does this mean that using the call on a large directory on network
volume is likely to block badly?
Yes. Though it depends on the protocol over which the directory is
being served as well as the filesystem in use at the other end. (In
some cases it may even depend on which implementation of the protocol
in question is being used.)
I'd be inclined to use getattrlist() instead of FSGetCatalogInfo(),
because in the latter case you'll have to go through the Carbon File
Manager (which will call getattrlist() itself anyway). Also, it's
likely that on filesystems that can't return the value you're after,
getattrlist() will tell you (by failing), whereas FSGetCatalogInfo()
will resort to an expensive directory traversal. That's usually a
benefit of using the File Manager routines (i.e. they implement a
fallback, in case the underlying system doesn't support what you're
after), but in this case it's probably better to deal with not being
able to get the entry count yourself.
You might see some mention of using the st_nlinks field from the
structure returned by stat(), which, when called on a directory, is
*sometimes* equal to 2 + <number of directory entries>.
Unfortunately, it isn't always equal to that; some implementations
set it to 2 + <number of subdirectories>, and there are probably
systems/filesystems out there that don't really set it to anything
useful at all. The POSIX spec. just says it's equal to the number of
hard links, but that isn't the behaviour exhibited by most flavours
of UNIX.
There are other problems with trying to get an entry count too,
including:
- Some volume formats (and some interfaces) count "." and/or ".." in
the entry
count for a folder. Some don't.
- Some volume formats may store the entry count as a "hint" rather
than requiring
it to be accurate.
- If you read the entry count, you can't rely on it being the same
after the call
returns.
e.g. it would be a bug to do this:
int num_entries = get_entry_count_for_directory ("/foo");
char **array_of_names = (char **) malloc (sizeof (char *) *
num_entries);
because someone (or something) could add a new file (or remove one)
before you'd read all the data.
Basically, asking for a count of the files in a directory isn't
really going to help you do anything terribly useful. You can't use
it to size data structures, and if you're going to display a list of
files to the user, you have to iterate through them one at a time
anyway (so you might as well count the ones you're iterating over,
because then you'll at least display consistent information).
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden