Re: FSRef speed impacts and permission checks
Re: FSRef speed impacts and permission checks
- Subject: Re: FSRef speed impacts and permission checks
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 15 May 2008 23:51:57 +0200
- Thread-topic: FSRef speed impacts and permission checks
On 15.05.2008 22:58 Uhr, "Mark Day" <email@hidden> wrote:
> If it's a depth first search, in what order do you visit
> subdirectories of previously visited directories? In theory, you
> should keep a list of to-be-visited directories, sorted by their
> directory ID
That's a good point about that order. Currently, I go by the name order,
i.e. the order in which I received them.
> In 10.5.0 and later, there is also dtrace. Attached is a shell script
> named "bufio".
I shall play with these things once I've got some time for this (currently,
I'm on a totally different project, but eventually I want to get back to
this one).
Thanks a lot! I'll report back to this list once I found out more.
BTW, did you see my feature request on radar (5909764)? There I ask for
better (faster) access to the hard link's inode number. All my questions on
this list eventually go down towards that goal: To scan a Time Machine
backup volume as fast as possible, _with_ identifying the hard links by
their inode IDs. While CatSearch is pretty fast for anything but inodes,
accessing the inodes using POSIX calls brings it to a crawl. So I'm trying
to understand what's the bottleneck in order to find other algorithms that
work out better. So far, your suggestion about the nodeID-ordered recursive
search is the best idea I've seen (yet, it's all only a work-around for the
lack of inode info from the CatalogInfo).
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